应更新业务排序字段（如sort_order）而非主键id，用ROW_NUMBER()或变量生成新序号；MySQL 5.7需用变量模拟；须在事务中执行并验证唯一性与连续性。
UPDATE时用ROW_NUMBER()重置自增序号（PostgreSQL / SQL Server / Oracle / MySQL 8.0+）
直接对自增列（如 id）执行 UPDATE 会失败——它要么是主键，要么由序列/IDENTITY约束保护。真正可行的方式是：用窗口函数生成新序号，再更新到业务排序字段（如 sort_order、rank），而非动主键。
常见错误是试图 UPDATE table SET id = ROW_NUMBER() OVER (ORDER BY created_at)，这在多数数据库中语法报错或违反约束。
- 必须确保目标字段（如
sort_order）不是主键、非自增、无唯一约束（或你已确认重排后仍满足唯一性） - 排序依据要明确：用
ORDER BY name还是ORDER BY updated_at DESC？顺序错了，重排就白做 - MySQL 5.7 及更早不支持窗口函数，得用变量模拟（见下一条）
- PostgreSQL 中若表很大，建议加
WHERE sort_order IS DISTINCT FROM ROW_NUMBER()...来跳过无需更新的行，减少锁和日志量
MySQL 5.7 用变量实现序号重排（兼容旧版本）
MySQL 5.7 不支持 ROW_NUMBER()，但可用用户变量临时计数。注意：变量行为在高并发或优化器重排执行顺序时不稳定，仅限单线程维护场景使用。
SET @row := 0; UPDATE my_table SET sort_order = (@row := @row + 1) ORDER BY name ASC;
关键点：
-
ORDER BY必须写在UPDATE语句末尾，否则变量递增顺序与预期不符 - 不能依赖
SELECT @row在同一语句中读写；必须分两步：先SET初始化，再UPDATE - 如果
sort_order有UNIQUE约束，需先DROP再重建，或用ALTER TABLE ... DISABLE KEYS（仅 MyISAM）——但风险高，不推荐
避免事务中断导致序号错乱
重排序号本质是全表逻辑变更，一旦中途失败（如超时、连接断开），可能留下部分更新、序号跳跃或重复，后续业务逻辑极易出错。
- 务必在事务中执行：
BEGIN; UPDATE ... ; COMMIT;，并确认数据库隔离级别允许语句级一致性（如 PostgreSQL 的READ COMMITTED即可） - 上线前先在副本库验证结果：
SELECT id, sort_order, ROW_NUMBER() OVER (ORDER BY sort_order) AS expected FROM my_table ORDER BY sort_order;，比对sort_order是否等于expected - 如果表有高频写入，考虑加应用层锁或停写窗口，否则新插入记录可能被挤进中间，破坏连续性
为什么不要重置主键自增值（AUTO_INCREMENT / SERIAL）
有人想“彻底清空重来”，尝试 ALTER TABLE ... AUTO_INCREMENT = 1 或 TRUNCATE，但这和“整理排序序号”是两回事——它只影响下一条插入的 ID，对已有数据的业务序号（如列表拖拽排序）毫无作用，反而可能引发外键冲突或历史记录关联断裂。
-
TRUNCATE会清空全部数据，不是重排 -
ALTER TABLE ... AUTO_INCREMENT = N仅设定下个插入值，不修改现有行 - 主键 ID 的语义是唯一标识，不是排序依据；把排序逻辑耦合到主键上，后期几乎无法重构
真正需要整理的，永远是那个显式声明的、用于控制展示顺序的字段——盯住它，别碰 id。
