row_number() 是生成连续行号的唯一可靠选择，因其严格递增、不重复、不跳号；必须搭配确定性 order by（如 order by status, id），否则结果不可复现，且缺 order by 会直接报错。
为什么 ROW_NUMBER() 是生成连续行号的唯一可靠选择
直接用 ROW_NUMBER()，别考虑 RANK() 或 DENSE_RANK()——它们会在值相同时跳号或并列，根本不符合“连续”要求。窗口函数里只有 ROW_NUMBER() 严格按排序顺序逐行递增，不重复、不跳过。
常见错误是漏写 ORDER BY 子句：SQL 标准强制要求 ROW_NUMBER() 必须带 OVER (ORDER BY ...)，否则报错 Window function requires an ORDER BY clause。即使业务上觉得“无所谓顺序”，也得显式指定一个确定性字段（比如主键 id），否则结果不可复现。
-
ORDER BY字段必须有确定性：避免用name这类可能重复的字段单独排序；加id做二级排序更安全，例如ORDER BY status, id - 不要在
WHERE之后再套ROW_NUMBER()：先过滤再编号，否则行号会断续（比如删掉第3行，后续行号仍是4、5…，但物理位置已空） - MySQL 8.0+、PostgreSQL、SQL Server、Oracle 都支持；SQLite 3.25+ 支持，旧版不支持
如何给分组内的数据独立编号
需要“每组从1开始编号”？就在 OVER 里加 PARTITION BY。它不改变连续性，只重置计数起点。比如按部门分组编号员工，每个部门内都是 1→2→3…
注意 PARTITION BY 和 ORDER BY 的执行顺序：先分区，再在每个区内排序并编号。如果漏掉 ORDER BY，即使写了 PARTITION BY，也会报错。
- 示例：
ROW_NUMBER() OVER (PARTITION BY dept_id ORDER BY hire_date)—— 每个部门按入职时间排号 - 不能用
PARTITION BY实现全局连续：它天生是局部编号，跨组不连贯（比如部门A最后是5，部门B第一个又是1） - 想“分组后仍全局连续”？别用
PARTITION BY，改用子查询嵌套或变量（但变量在多数SQL引擎中不稳定，不推荐）
ORDER BY 用表达式或多个字段时的坑
排序依据若含计算或函数（如 UPPER(name)），必须确保结果确定：相同输入永远产出相同排序值。否则同一语句多次执行可能得到不同行号，尤其在分布式数据库或并行执行场景下。
多字段排序时，等值字段必须能被后续字段打破平局。否则 ROW_NUMBER() 会在这些行上任意分配序号（虽连续，但不可预测）。
- 危险写法：
ORDER BY category（category 有大量重复值）→ 行号分配顺序无保证 - 安全写法：
ORDER BY category, created_at, id→ 时间戳+主键兜底，彻底消除不确定性 - 避免
ORDER BY RAND()：虽然语法合法，但每次运行结果不同，完全失去“连续行号”的可复现意义
性能和兼容性要注意什么
ROW_NUMBER() 是计算密集型操作，尤其在大数据量 + 复杂排序时。数据库需先完成全部排序，再编号，无法流式处理。没有索引支撑的 ORDER BY 字段会导致全表排序，IO 和内存压力陡增。
- 关键优化：为
ORDER BY字段建索引，特别是组合排序字段（如(dept_id, hire_date, id)） - PostgreSQL 中，
ROW_NUMBER()在LIMIT前计算，意味着即使只取前10行，也得先给全表编号；如只需 Top-N 编号，考虑用 CTE 先LIMIT再编号 - SQL Server 的
TOP N WITH TIES和ROW_NUMBER()组合容易混淆：WITH TIES 返回并列行，但ROW_NUMBER()仍按原始顺序编号，两者逻辑不自动对齐
连续行号看着简单，真正落地时，排序确定性、分组边界、执行计划这几处最容易出问题——尤其当数据量涨到百万级以后，ORDER BY 字段有没有索引，直接决定这条语句是秒出还是卡死。
