UPDATE索引列会触发索引结构变更，需先删除旧索引项再插入新项，涉及聚簇索引和所有相关二级索引的同步更新，导致写放大、页分裂及I/O开销陡增。
UPDATE索引列会触发索引结构变更
MySQL的B+树索引不是只读目录，而是实时维护的数据结构。每次更新一个被索引的列，InnoDB必须同步调整所有涉及该列的索引：包括聚簇索引（如果更新的是主键）和所有二级索引（只要该列出现在索引定义中）。这不只是“改一行数据”，而是“改一行 + 改多个索引页”。
- 更新非索引列（如
description）时，只需修改聚簇索引叶子节点里的对应字段，其他索引完全不动 - 更新索引列（如
status，且存在INDEX idx_status (status)）时，InnoDB要先从二级索引中删除旧值对应的索引项，再插入新值项——相当于一次DELETE + 一次INSERT操作 - 若该列是联合索引的一部分（如
(user_id, status)），哪怕只改status，整个索引项也要重写，因为B+树里存储的是完整键值对
回表与二级索引更新开销被隐式放大
很多人以为“只是改个字段”，但实际执行路径远比想象复杂。尤其当更新的是二级索引的**包含列**（INCLUDE 不是 MySQL 原生语法，但类似效果可通过覆盖索引模拟）或**键列**时，代价会陡增。
- 如果
UPDATE user SET name = 'Alice' WHERE id = 123，而name在某个二级索引中是包含列（比如通过冗余字段或联合索引实现），那这个二级索引页也得刷新 - 更隐蔽的是：即使你没显式建索引，
PRIMARY KEY和所有UNIQUE约束列都自带索引。更新这些列，必然触发聚簇索引重组——可能引发页分裂、缓冲池淘汰、redo log 写入激增 - 用
SHOW INDEX FROM table_name检查目标列是否出现在任何Key_name下；只要出现，就属于“索引列”
统计信息不准会导致优化器误判更新代价
MySQL优化器在生成UPDATE执行计划时，会参考索引的选择性（distinct values / total rows）。如果统计信息陈旧，它可能低估索引更新成本，选错执行路径——比如该走全表扫描批量更新时，却强行走索引逐行定位，结果I/O雪崩。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 执行
SELECT COUNT(DISTINCT status) / COUNT(*) AS selectivity FROM orders;，若结果 status 列基数极低，但你又建了索引，那每次更新都在为低效结构付费 - 运行
ANALYZE TABLE orders;强制刷新统计信息，再对比EXPLAIN FORMAT=JSON UPDATE ...中的rows_examined是否大幅下降 - 特别注意：MySQL 8.0+ 默认启用
innodb_stats_auto_recalc=ON，但大表批量导入后仍建议手动ANALYZE
锁粒度和并发冲突在索引列更新时更敏感
更新索引列不仅改数据，还直接改变索引树的搜索路径。这意味着：同一索引页上的多行更新更容易产生页级锁争用；而更新非索引列，锁通常只落在具体行记录上。
- 例如对
idx_created_at (created_at)索引列执行UPDATE ... SET created_at = NOW()，所有匹配行可能集中在同一个B+树叶子页（因时间相近），导致PAGELATCH_EX等待飙升 - 用
SELECT * FROM sys.innodb_lock_waits;或performance_schema.data_locks查看锁等待类型，若高频出现RECORD锁但LOCK_DATA显示相同页号，大概率是索引页争用 - 规避方式：避免在高频更新场景下，对高聚集度字段（如时间戳、状态码）建单列索引；改用复合索引把这类字段放在右侧，降低其对树结构的影响
索引列更新慢的本质，不是“写磁盘慢”，而是“写完还得同步修好所有导航地图”。容易被忽略的是：哪怕你只改一个字节，只要它在任一索引定义里，InnoDB就必须确保所有索引视图的一致性——这个一致性保障过程，才是真正的性能杀手。
