会，update主键会强制触发聚簇索引物理重排，本质是“删旧行+插新行”的原子操作，需同步更新所有二级索引，并可能引发页分裂、锁争用与i/o放大。
UPDATE主键会触发聚簇索引重排吗
会，而且是强制、同步、不可跳过的物理重排。MySQL（InnoDB）中主键即聚簇索引，数据行直接存储在B+树的叶子节点里。一旦执行UPDATE t SET id = ... WHERE ...，旧id对应的数据页必须被定位、标记为“逻辑删除”，新id对应的位置要分配空间、写入完整行——这不是简单改个值，而是“删一行 + 插一行”的原子操作。
常见错误现象：SHOW ENGINE INNODB STATUS里频繁出现insert buffer合并延迟；innodb_buffer_pool_pages_misc突增；慢日志中UPDATE语句Rows_examined远大于Rows_affected。
- 即使新旧id相邻（如从1001→1002），只要B+树结构需维持有序性，就可能触发页分裂或合并
- 若表有二级索引，每个二级索引叶节点都存着旧id值，更新后必须全部回查聚簇索引并重写——锁范围和I/O放大数倍
- 复合主键（如
(order_id, item_seq)）更新任一字段，整条聚簇索引记录都要迁移
为什么按主键顺序批量UPDATE也不能避免死锁
按id升序查出ID再拼IN列表，只解决了一半问题：它能减少间隙锁（Gap Lock）竞争，但无法规避聚簇索引页面级的物理冲突。当多事务并发更新不同id但落在同一数据页时，仍会争抢该页的X锁。
使用场景：订单状态迁移（UPDATE orders SET id = id + 100000 WHERE status = 'pending'）这类业务误用主键做“版本号”或“迁移标识”时，极易触发大面积页锁等待。
-
SELECT id FROM t WHERE ... ORDER BY id拿到的只是逻辑顺序，InnoDB实际存储页可能因历史分裂而物理错乱 - ORM（如Django ORM、MyBatis）默认对
IN列表内部做排序，但不保证传给MySQL的wire protocol顺序，需显式验证Payload内容 - 真正安全的做法是拆成单条
UPDATE ... WHERE id = ?，并确保应用层串行化或加应用锁
status这类高频更新字段加索引的代价到底在哪
代价不在查询快不快，而在每次UPDATE都要同步刷三处：聚簇索引页、所有含该字段的二级索引页、redo log buffer。哪怕只更新status一个TINYINT列，只要它在某个联合索引里（如INDEX (status, created_at)），整个索引项就得重写——B+树节点大小固定，新值长度变化就会引发页分裂。
性能影响实测阈值：单表每秒UPDATE超50次，且目标字段参与索引，innodb_row_lock_time_avg通常会上涨300%以上。
- 区分度低的字段（如
status只有3个值）会让cardinality统计严重失真，优化器更倾向放弃走索引 -
ANALYZE TABLE不能实时生效，大表上执行会阻塞DML，生产环境慎用 - 替代方案比硬加索引更可控：比如把
status查询需求下沉到物化视图或冗余字段（is_shipped_flag TINYINT），后者几乎不更新
什么情况下必须更新主键
极少。真实业务中99%的“需要改主键”其实是设计缺陷：比如用身份证号、手机号作主键后发现要脱敏；或分库分表时强行重编号。InnoDB本身不提供安全、低开销的主键变更路径。
如果真绕不开，唯一可接受的操作是停写 + ALTER TABLE ... DROP PRIMARY KEY, ADD PRIMARY KEY (new_id)，而不是用UPDATE逐行改——后者在千万级表上可能跑数小时，期间锁表风险极高。
容易被忽略的点：即使你没显式UPDATE主键，某些ORM的“全量更新”模式（如save()无条件覆盖所有字段）也可能意外带上主键列，导致隐式变更。务必检查生成的SQL或开启general_log抓包验证。
