UPDATE主键会强制重定位数据行，触发删除+插入操作，导致页分裂、空洞和锁升级；修改二级索引列同样引发聚簇索引与二级索引双树维护，开销更大；主键应视为不可变标识。
UPDATE主键列会强制触发聚簇索引重定位
InnoDB的聚簇索引要求数据行严格按主键值物理排序存储。一旦执行UPDATE t SET id = ? WHERE id = ?，原行必须从旧位置彻底移出，并插入到新主键值对应的新页中——这不是“修改”，而是“删除+插入”两步操作。这会同时引发：原页留下空洞、目标页可能因空间不足而分裂、父节点指针需更新，甚至向上递归分裂到根节点。
二级索引字段UPDATE比主键更隐蔽但开销更大
修改非主键索引列（如UPDATE t SET name = 'new' WHERE id = 123）时，InnoDB需同步维护聚簇索引行和name二级索引页。若新name值变长，可能触发聚簇索引页内行迁移；若新值排序位置变化，还会在name索引树中删除旧条目+插入新条目——等于一次主键UPDATE + 一次二级索引INSERT，两棵树都可能分裂。
自增主键表也不能随便UPDATE主键
- 即使主键是
BIGINT AUTO_INCREMENT，只要UPDATE后的新值不是严格递增（比如设成更小的数），就破坏了顺序性，导致目标页大概率不是末尾页，分裂无法避免 -
innodb_fill_factor对这类UPDATE无效——它只影响新页的初始填充比例，不干预已有页的重定位逻辑 - 常见误用：
UPDATE t SET id = LAST_INSERT_ID() + 1，看似“续号”，但并发下极易写入乱序页，反而加剧分裂
监控和规避的关键信号
真正危险的UPDATE主键行为，往往伴随以下指标突变：
-
Innodb_page_splits陡升，且Innodb_pages_written远高于Innodb_pages_read -
Handler_read_rnd_next持续走高，说明查询被迫随机跳页访问 -
information_schema.INNODB_TRX中出现大量LOCK_WAIT，常因页分裂期间锁升级为意向排他锁（IX）阻塞其他事务 -
SHOW TABLE STATUS里Data_free缓慢但持续增长，说明空洞未被复用
最稳妥的做法：主键一旦生成，就当作不可变标识。状态变更、排序调整等需求，应该通过新增普通字段或冗余索引来承载，而不是动主键本身。
