先来聊一点 ROW_NUMBER() 的硬核知识点。这个函数在 SQL 里很常用，但真上手时，细节上稍不注意就容易翻车。下面就把几个最容易被忽略的“坑”说清楚。
ROW_NUMBER() 必须配合 OVER() 才能生效
单独写 ROW_NUMBER() 直接跑，十有八九要报错。比如 SELECT id, ROW_NUMBER() 这么来一句，数据库会毫不客气地告诉你“窗口函数必须有 OVER 子句”。它不是那种随便就能调用的标量函数，它本质上是窗口函数，排序和分组逻辑都依赖 OVER 来定义。
最常见的一个语法错误是漏掉了 ORDER BY。别忘了，OVER() 里面至少要有个 ORDER BY，否则语法根本过不去。那如果就是想给整个结果集从1排到N，按自然顺序编号呢？可以用主键或时间字段来解决，比如 OVER (ORDER BY id) 或 OVER (ORDER BY created_at)。
OVER (ORDER BY col1, col2)：先按 col1 排，相同时再按 col2 排，相当于联合排序后统一编号。OVER (PARTITION BY dept_id ORDER BY salary DESC)：先按部门分小组，每个小组内再按薪资降序编号。- 绝对不能写
OVER ()（空括号），也不能只写OVER (PARTITION BY x)而不带ORDER BY——这两种写法在大多数数据库里都过不了编译。
多表 JOIN 后编号，ORDER BY 列必须来自结果集
多表 JOIN 之后再用 ROW_NUMBER()，这事儿稍微一复杂就容易翻车。关键点是：ORDER BY 只能引用最终 SELECT 列表中明确出现的字段，或者原始表里没有歧义的列。如果两张表都有 id，直接写 ORDER BY id 必然报“列名不明确”。
更稳妥的做法是：
- 给 JOIN 后的字段起别名，比如
SELECT u.id AS user_id, o.order_id，然后在 OVER 里用ORDER BY user_id, order_id来引用。 - 如果字段名唯一，也可以用表别名来限定，例如
ORDER BY u.created_at, o.amount，前提是表别名已经在查询里定义好。 - 还有一个容易忽略的点：
ORDER BY中引用的字段，最好是在 SELECT 列表里出现过。MySQL 8.0+ 和 SQL Server 对此要求很严，某些数据库（比如 PostgreSQL）宽松一些但也不推荐依赖。
编号从 1 开始，且严格连续，不受 WHERE 或 LIMIT 影响
这一点很容易踩进去：ROW_NUMBER() 生成的编号是在窗口计算阶段完成的，而窗口计算发生在 WHERE 过滤和 LIMIT 截断之前。这意味着什么？
如果先给全量数据编号，再在外面套一个 WHERE status = 'active'，编号仍然是基于全量 JOIN 结果生成的，所以过滤后编号会跳跃（比如原编号 1,2,3,4,5，过滤掉第2条后，变成 1,3,4,5）。
如果想要对过滤后的结果重新编号，思路很明确：把过滤逻辑放到子查询或 CTE 里面，让窗口函数在过滤后的结果集上运行。举个例子：
SELECT *, ROW_NUMBER() OVER (ORDER BY user_id) AS rn FROM ( SELECT u.id AS user_id, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' ) t
这样出来的 rn 才是针对“已支付订单”这个过滤后集合的连续编号，不会跳跃。
不同数据库对 NULL 的排序行为不一致
这一点属于“知道就不吃亏”的细节。ROW_NUMBER() 本身不处理 NULL，但 ORDER BY 遇到 NULL 时，不同数据库的表现可差得太远了。MySQL 默认把 NULL 放最前面，PostgreSQL 默认放最后，SQL Server 则取决于 SET ANSI_NULLS 设置。这就意味着，同样的 SQL 在不同数据库里跑出来的编号顺序可能完全不一样。
所以，一个保险的做法是显式控制 NULL 的位置：
- 用
ORDER BY COALESCE(updated_at, '1970-01-01')把 NULL 替换成一个明确的边界值。 - 或者用
ORDER BY col IS NULL, col（MySQL 和 PostgreSQL 都支持），让 NULL 乖乖排到末尾。 - 千万别依赖数据库默认的 NULL 排序习惯，尤其是在跨库迁移或读写分离的场景下，一旦默认行为变了，结果就会悄然出错。
总的来说，多表关联后做 ROW_NUMBER() 看起来简单，真正踩坑的地方往往不在语法本身，而在于排序语义是否与业务预期一致——特别是涉及 NULL、JOIN 字段歧义、以及过滤时机这些细节。把这几块理清楚了，基本就不会翻车。
