row_number()必须配合over子句使用，否则报错；它属窗口函数，强制要求over中含order by排序逻辑，不可单独调用，也不能与group by混用，正确做法是先编号再过滤。
ROW_NUMBER() 必须配合 OVER 子句使用
直接写 SELECT ROW_NUMBER() 会报错，因为 ROW_NUMBER() 是窗口函数，没有 OVER 就不知道按什么排序、分什么组。常见错误是漏掉括号或写成 OVER () —— 空括号在多数数据库（如 PostgreSQL、SQL Server）中不合法，MySQL 8.0+ 虽允许但实际行为未定义，容易出错。
- 必须写
OVER (ORDER BY column_name)，哪怕只是按主键排序：例如ROW_NUMBER() OVER (ORDER BY id) - 如果想按插入顺序编号，且表无可靠时间戳字段，
ORDER BY id（自增主键）是最常用也最稳妥的选择 - 不能用
ORDER BY RAND()配合ROW_NUMBER()来“随机编号”——结果不可复现，且不同执行可能产生不同行号
ORDER BY 中的 NULL 值会影响行号连续性
ROW_NUMBER() 按 ORDER BY 的逻辑顺序严格编号，而 NULL 在排序中默认排在最前（PostgreSQL、SQL Server）或最后（MySQL 默认），这会导致编号看起来“跳号”或“从中间开始”，其实不是函数问题，是排序结果本身有空值干扰。
- 检查
ORDER BY字段是否含 NULL：用WHERE column_name IS NOT NULL过滤，或用COALESCE(column_name, 'default_value')统一处理 - 显式控制 NULL 位置：例如
ORDER BY column_name ASC NULLS LAST（PostgreSQL 支持），MySQL 和 SQL Server 需用ORDER BY CASE WHEN column_name IS NULL THEN 1 ELSE 0 END, column_name - 别指望靠
ROW_NUMBER()“自动跳过 NULL 行并保持 1,2,3… 连续”——它编号的是结果集里的每一行，包括 NULL 所在行
WHERE 和 ROW_NUMBER() 的执行顺序很关键
ROW_NUMBER() 在 WHERE 之后、ORDER BY 之前计算（标准 SQL 执行顺序）。这意味着：你不能在 WHERE 中直接引用 ROW_NUMBER() 别名，比如 WHERE rn > 10 会报错“列不存在”。
- 要筛选行号，必须用子查询或 CTE：先算出
ROW_NUMBER()，再在外层查中过滤，例如：SELECT * FROM (SELECT *, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM users) t WHERE t.rn BETWEEN 21 AND 30
- 分页时别用
LIMIT/OFFSET+ROW_NUMBER()叠加——既低效又易错；优先用原生分页语法（如 PostgreSQL 的OFFSET/LIMIT，MySQL 的LIMIT offset, size） - 如果业务逻辑真需要“跳过前 N 行后取 M 行且带编号”，CTE 是最清晰写法，避免嵌套过深
不同数据库对 ROW_NUMBER() 的兼容性差异
基本语法一致，但边界行为和性能表现有区别。MySQL 5.7 不支持窗口函数，必须升级到 8.0+；SQLite 直到 3.25.0（2018 年）才加入，旧版本会直接报错。
- SQL Server 支持
ORDER BY后加ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但ROW_NUMBER()本身不关心帧定义，加了也没用 - PostgreSQL 允许
OVER ()（即无ORDER BY），但行号顺序不确定，不建议依赖 - Oracle 中
ROWNUM是伪列、非窗口函数，和ROW_NUMBER()行为不同：前者在结果生成时分配，后者在排序后分配，二者不能混用
真正麻烦的不是怎么写 ROW_NUMBER()，而是搞清你要编号的对象到底是不是已经过滤、排序、去重后的最终结果集——很多“行号不连续”“起始不是 1”的问题，根源都在子查询层级或 WHERE 位置没理清。
