row_number() 是查询时生成的虚拟序号，不修复原序列缺漏；重排id需用cte+update并谨慎处理主键与外键约束，否则破坏数据一致性。
ROW_NUMBER() 不能“修复”丢失的序列号，它只生成新序号；想重排必须用它覆盖原字段，且需谨慎处理主键或业务唯一性约束。
为什么 ROW_NUMBER() 不是“修复”，而是“重生成”
很多人看到表里 id 字段有空缺（比如 1,2,4,5，缺了 3），就以为 ROW_NUMBER() 能“补上”那个 3。其实它根本不管原始值——它只是在当前查询结果集上，按 ORDER BY 重新从 1 开始编号。原始 id 是多少，它完全无视。
常见误操作：
- 直接 UPDATE t SET id = ROW_NUMBER() OVER (ORDER BY id) → 报错或逻辑混乱（MySQL 不允许在 UPDATE 中对同一表用窗口函数）
- 用 SELECT *, ROW_NUMBER()... 查出来就当“修好了” → 实际没改表，下次再查还是老样子
- ROW_NUMBER() 是查询时计算的虚拟列，不修改物理存储
- 它生成的是连续整数，但和原
id是否“丢失”无关 - 若原
id是主键或外键引用，强行重排会破坏数据一致性
真要重排 ID，得走三步：CTE + 自增临时列 + 替换
安全重排的前提：该字段不是主键、没被外键引用、业务层不依赖其连续性。否则别动。
以 MySQL 8.0+ 为例，假设你有一张 logs 表，log_id 有空缺，你想按 created_at 时间顺序重排成连续编号：
WITH numbered AS (
SELECT log_id, created_at, content,
ROW_NUMBER() OVER (ORDER BY created_at, log_id) AS new_id
FROM logs
)
UPDATE logs l
JOIN numbered n ON l.log_id = n.log_id
SET l.log_id = n.new_id;
- 必须用 CTE 或子查询包裹
ROW_NUMBER()，否则 MySQL 禁止在 UPDATE 中直接调用 -
ORDER BY created_at, log_id防止时间相同时排序不稳定（避免每次执行结果不同） - 执行前务必备份：
CREATE TABLE logs_backup AS SELECT * FROM logs; - 如果
log_id是主键，UPDATE 前需先DROP PRIMARY KEY，更新后再重建（高风险，慎用）
更常见的需求其实是“逻辑重排”，不是物理改 ID
多数时候你并不需要真改 id 字段，而是希望查询时显示“第 1 条、第 2 条……”这种稳定序号——这才是 ROW_NUMBER() 的正确打开方式。
例如报表展示用户操作日志，按时间倒序排列并标序号：
SELECT ROW_NUMBER() OVER (ORDER BY created_at DESC, log_id DESC) AS seq, log_id, content, created_at FROM logs WHERE status = 'active';
-
seq是纯展示用的行号，不影响任何业务逻辑 - WHERE 过滤后
ROW_NUMBER()依然从 1 开始，这是预期行为，不是 bug - 若要分页取第 2 页（每页 10 条），直接加
WHERE seq BETWEEN 11 AND 20，比LIMIT 10 OFFSET 10更稳定（尤其数据动态增删时） - 注意：
ORDER BY必须包含足够区分度的字段（如加log_id），否则相同时间的多条记录每次查询序号可能乱序
真正容易被忽略的点：重排 ID 是运维动作，不是查询动作；而 ROW_NUMBER() 是查询动作，天生不该承担数据修复职责。用错场景，轻则结果不可复现，重则引发外键断裂或应用报错。
