断层序号指原始ID存在跳跃（如1,2,4,7），需生成连续新序号（1,2,3,4）；ROW_NUMBER()仅按排序位置编号，不修复语义断层，应先用ROW_NUMBER()生成序号再关联原表映射，而非依赖DENSE_RANK()或单窗口函数。
断层序号是什么，为什么不能直接用 ROW_NUMBER()
断层序号指原始数据中 id 或业务序号存在跳跃（比如 1,2,4,7,8），而你希望生成连续、无跳空的新序号（1,2,3,4,5）。这时候别急着用 ROW_NUMBER() OVER (ORDER BY id) —— 它只按排序位置编号，不感知“断层”，但如果你的排序字段本身就有空缺，结果看似连续，实际和业务语义脱节。真正要修的是“按逻辑顺序重排”，不是“按当前行位置编号”。
用 DENSE_RANK() 代替 ROW_NUMBER() 的适用场景
当断层源于重复值需要合并编号时（例如同一订单有多条明细，你希望所有明细共享一个订单序号），DENSE_RANK() 更合适。它对相同排序键赋予相同序号，且后续序号不跳空。
- 输入：
ORDER BY order_date, order_id，若两天内有 3 笔相同order_id，它们都得排第 1 -
ROW_NUMBER()会给出1,2,3；DENSE_RANK()给出1,1,1,2,... - 注意：
DENSE_RANK()不解决纯数值断层（如id=100,105,106），它只响应ORDER BY键的相等性
真正修复数值型断层：先 ROW_NUMBER()，再映射回原字段
如果目标是把 id 列从 [100,105,106,110] 映射为 [1,2,3,4]，核心思路是：用 ROW_NUMBER() 生成新序号，再通过子查询或 CTE 关联回原表。不能指望单个窗口函数“自动理解你要修哪个列”。
- 必须明确排序依据：通常是
ORDER BY id，确保物理顺序与业务顺序一致 - 写法示例（标准 SQL）：
SELECT t.*, rn AS new_seq FROM your_table t JOIN ( SELECT id, ROW_NUMBER() OVER (ORDER BY id) AS rn FROM your_table ) r ON t.id = r.id;
- MySQL 8.0+ / PostgreSQL / SQL Server 都支持；旧版 MySQL 需用变量模拟，但易出错，不推荐
- 别在
WHERE中过滤后再窗口编号——断层修复依赖全集排序，提前过滤会改变序号基线
性能与边界坑点：NULL、重复、大数据量
断层修复不是纯语法问题，实际跑起来容易卡在三个地方：
-
ORDER BY字段含NULL：不同数据库默认处理不同（PostgreSQL 把NULL排最前，MySQL 可能排最后），导致序号错位。显式写ORDER BY id ASC NULLS LAST（如果支持）或先COALESCE(id, 999999999) - 排序键重复且无第二排序字段：
ROW_NUMBER()结果不确定（相同id行每次执行序号可能互换），加ORDER BY id, ctid（PostgreSQL）或ORDER BY id, %%physloc%%（SQL Server）保稳定 - 千万级以上表直接
JOIN子查询可能慢：改用ROW_NUMBER()作为计算列 + 覆盖索引加速ORDER BY，避免排序落盘
真正麻烦的不是函数怎么写，而是你得先确认：这个“断层”是脏数据导致的，还是业务上就该保留（比如删除记录后留空档）。盲目重排可能破坏外键引用或审计线索。
