MySQL中UPDATE主键本质是“删旧+插新”的物理迁移，非原地修改，会触发多次行锁、间隙锁及二级索引全量重写，极易引发死锁与性能退化。
UPDATE主键本质是物理迁移，不是原地修改
MySQL（InnoDB）从不“就地更新”主键值。当你执行 UPDATE t SET id = 101 WHERE id = 1，InnoDB 实际执行的是：先在聚簇索引中定位并标记旧记录为删除（加 X 锁），再在新主键位置插入一条全新记录（加 X 锁 + Gap Lock）。这个“删旧+插新”过程不可原子化，在并发下会被其他事务观察到中间态。
这意味着：哪怕只改一行，也至少触发两次行级锁操作；若新位置被间隙锁封锁，还会引发等待；若涉及二级索引，每条二级索引项都要重写——这会反向查找聚簇索引、再次加锁，锁扩散远超 SQL 表面所见。
主键变更强制重建所有二级索引
主键是聚簇索引的键，而所有二级索引的叶子节点都存着主键值。一旦 id 被 UPDATE，InnoDB 必须同步更新每个二级索引中对应的所有索引项。例如表上有 INDEX idx_status_created (status, created_at)，而你执行 UPDATE t SET id = id * 2 WHERE status = 'pending'，即使 status 有索引，InnoDB 仍需：
- 扫描
idx_status_created找出所有status = 'pending'的记录 → 加 S 锁或 X 锁 - 对每条匹配记录，根据其叶子节点里的旧
id去聚簇索引查原行 → 可能再加 X 锁 - 用新
id重构该二级索引项 → 再次触发聚簇索引定位和加锁
这种“索引链式加锁”会让锁范围指数级扩大，尤其当二级索引基数大、重复值多时，极易与其它事务形成环形等待。
WHERE条件没走索引时，等于手动加表锁
如果更新语句的 WHERE 条件无法命中索引（比如 UPDATE t SET id = id + 1 WHERE name LIKE '%abc%'），InnoDB 在 RR 隔离级别下会：
- 全表扫描每行，对**所有扫描到的记录加 X 锁**
- 对**所有扫描经过的间隙加 Gap Lock**（防止幻读）
- 不同事务因缓冲池状态、B+树遍历路径差异，可能以相反顺序加锁 → 经典死锁四元组
此时即使只改主键，效果等同于隐式表锁。高并发下，SHOW ENGINE INNODB STATUS\G 中的 TRANSACTIONS 段会显示大量 LOCK WAIT，且锁住的不只是目标行，而是整段索引区间。
替代方案：用业务唯一键代替主键更新
真正需要“重编号”或“迁移ID”的场景极少。绝大多数所谓“更新主键”，实际是业务逻辑误用。更安全、低开销的做法是：
- 保留自增
id作为物理主键，永不更新 - 新增一个带业务含义的唯一字段（如
business_code），用它承载可变标识逻辑 - 所有对外暴露、前端传参、API 路由使用的 ID，都基于该业务字段，而非
id - 真要重映射时，用
INSERT ... ON DUPLICATE KEY UPDATE替代UPDATE ... SET id = ...，避免删插迁移
主键的稳定性不是设计约束，而是 InnoDB 锁机制的硬性要求。频繁修改主键，相当于主动绕过引擎最优化的路径，把行锁问题升级为索引结构震荡问题——这点在批量任务、数据迁移、灰度发布等场景中尤其致命。
