MySQL更新主键本质是“删旧+插新”的物理迁移，非原地修改，会触发B+树分裂合并、全量二级索引重写及外键级联更新，导致严重锁开销与性能退化。
主键值修改直接冲击B+树结构
MySQL的主键索引本质是聚簇索引，数据行就按主键顺序物理存储在B+树的叶子节点里。一旦你执行 UPDATE table SET id = 100 WHERE id = 1，不只是改一个值，而是把整行从原位置“搬走”，再插入到新主键对应的位置——这会触发B+树的分裂、合并与节点重平衡。
常见错误现象：语句执行慢、锁表时间长、SHOW PROCESSLIST 中看到大量 Waiting for table metadata lock 或 Updating 状态。
- 即使只改一条记录，InnoDB也要先定位原页、标记删除、再定位目标页、插入新行（相当于 delete + insert）
- 若新ID落在已有数据区间内（比如从 5 改成 3），可能引发多个页的连锁调整
- 所有二级索引（非主键索引）都包含主键值作为“指针”，主键变更后，每个二级索引项也必须同步更新
外键和二级索引联动加重开销
主键不是孤立存在的。只要表上有外键引用，或存在任何二级索引（INDEX、UNIQUE KEY），修改主键就会触发级联更新。这不是“顺便更新”，而是强制事务内原子完成。
使用场景：比如订单表 orders 的 id 被订单明细表 order_items 的 order_id 外键引用——此时修改 orders.id，MySQL 必须检查并更新所有关联的 order_items 行（除非定义了 ON UPDATE CASCADE，但即便如此，仍是批量I/O）。
- 没有
ON UPDATE CASCADE？操作直接报错：Cannot delete or update a parent row: a foreign key constraint fails - 有
CASCADE？实际执行等价于先查出所有子记录，再逐条UPDATE，每条都走索引查找+更新路径 - 哪怕只是单字段二级索引，也要重写该索引中对应的所有叶节点项（因为索引项里存着旧主键值）
为什么 ALTER TABLE 修改主键列类型更危险？
ALTER TABLE t MODIFY id BIGINT 或 CHANGE id id BIGINT PRIMARY KEY 不是“改个定义”那么简单。它强制重建整张表，且重建过程无法规避全量索引重建。
性能影响非常直观：表越大，耗时越长；期间表不可写（ALGORITHM=INPLACE 对主键列变更基本无效）；临时磁盘空间需达原表 2–3 倍。
- 原因在于：主键列类型变更 → 数据行长度变化 → B+树页结构重分配 → 所有索引（含聚簇索引）必须重新构建
-
AUTO_INCREMENT属性变更（如重置起始值）不触发重建，但修改主键列本身一定会 - InnoDB 的
ROW_FORMAT=COMPACT或DYNAMIC下，变长类型（如VARCHAR）扩大也可能间接导致页分裂加剧
替代方案比硬改主键更现实
真正需要“重排ID”的场景（比如清理空洞、归一化编号），几乎都不该动主键值。优先考虑业务层可控的替代路径。
容易踩的坑：有人用 SET @i:=0; UPDATE t SET id=(@i:=@i+1) ORDER BY id; —— 这在并发环境下极易产生主键冲突或唯一键报错，且无法回滚部分失败。
- 安全做法：新增一个
sort_order或seq_no字段，用它做逻辑排序，主键保持不变 - 真要重编号：导出数据 → 清空表（
TRUNCATE）→ 重设AUTO_INCREMENT→ 重新导入，避开在线修改 - 涉及外键时，必须先
DROP FOREIGN KEY，改完再ADD，否则 DDL 直接失败
主键的本质是唯一标识，不是序号。把它当序号用，迟早要为索引重排买单。
