MySQL写操作需同步更新所有相关索引，每条INSERT/UPDATE/DELETE触发多次B+树维护，导致随机I/O激增、change_buffer失效、页分裂频繁、锁竞争加剧及索引碎片化，显著拖慢读写性能。
INSERT/UPDATE/DELETE时每个索引都要同步更新
MySQL在执行写操作时，不是只写数据行——它必须为INSERT的每一行、UPDATE涉及的每个被修改列、DELETE的每条记录，在所有相关索引的B+树中做对应插入、分裂、删除或重平衡。假设一张表有7个二级索引，执行一条INSERT，实际会触发：1次主键聚簇索引写入 + 7次二级索引写入 = 8次独立的B+树维护操作。
这不是“顺带更新”，而是强制同步：事务提交前，所有索引页变更必须落盘（或至少进入redo log），否则ACID无法保证。高并发下，这些操作会争抢buf_pool中的页缓存、锁住索引页（如latch）、触发大量随机I/O。
- 唯一索引还额外增加一次duplicate check（需先查再写），无法用
change_buffer优化 -
UPDATE若修改了索引列（如WHERE id = ? SET status = ?且status有索引），要先从旧索引页删掉旧值，再往新索引页插入新值——两次B+树操作 -
DELETE同理，每个索引都要执行一次叶节点删除，可能引发页合并（merge）开销
随机I/O暴增 + change_buffer失效场景多
聚集索引（主键）通常按自增顺序写入，物理上连续；但二级索引的键值往往是离散的（比如email、created_at），导致每次写入都可能命中不同磁盘位置的索引页。这就是典型的随机I/O模式——SSD尚可扛住，HDD直接卡死。
MySQL的change_buffer本可缓解这个问题：把非唯一二级索引的变更先缓存在内存里，等页被读入buffer pool时再合并。但它有硬限制：
- 对唯一索引无效（必须立刻检查是否冲突）
- 对主键/聚簇索引无效
- 当buffer pool压力大、change_buffer满载或页已加载时，立即刷盘
- 大批量写入时，change_buffer本身也会成为CPU和内存瓶颈
也就是说：你建的越多唯一索引（如UNIQUE(email)、UNIQUE(phone)），change_buffer能帮你省下的I/O就越少。
页分裂频发 + 索引碎片反向拖累查询
二级索引键值随机性越高，B+树页的填充率越难维持。InnoDB默认页填充率为15/16（约93.75%），一旦新键值插不进当前页，就触发页分裂：原页拆成两个，部分记录迁移，父节点更新指针。这个过程消耗CPU、产生磁盘碎片、并让索引页在物理上变得不连续。
后果是双重的：
- 写入变慢：每次分裂都要分配新页、拷贝记录、更新父节点，开销远高于顺序追加
- 后续查询也变慢：范围扫描（
WHERE created_at BETWEEN ? AND ?）需要跨多个物理分散的页读取，Innodb_buffer_pool_read_requests与Innodb_buffer_pool_reads比值持续低于95%，就是典型信号
注意：OPTIMIZE TABLE能重建索引、合并页、重排物理顺序，但它本身是重量级DDL，会阻塞写入，且对大表可能引发从库延迟——治标不治本。
锁竞争加剧，尤其在高并发更新场景
InnoDB的行锁本质是加在索引记录上的。索引越多，同一行数据在不同索引树中对应的“锁锚点”就越多。例如更新user_id = 123的city字段，如果city、(user_id, city)、(city, status)都有索引，那这次更新可能同时持有3个不同索引页上的记录锁或间隙锁。
这直接导致：
- 锁等待时间拉长：事务要等齐所有相关索引页的锁释放
- 死锁概率上升：多个事务以不同顺序访问多个索引页，极易形成环路
- 热点页争抢：比如按
status分组的高频更新，会让idx_status所在索引页成为“锁热点”
真实案例中，某订单表因冗余索引过多，在促销期间UPDATE ... SET status = 'paid'批量操作平均耗时从40ms升至320ms，SHOW ENGINE INNODB STATUS里频繁出现*** (1) WAITING FOR THIS LOCK TO BE GRANTED:记录。
索引数量本身不是原罪，问题出在“未被查询使用却仍被强制维护”的索引上——它们安静地躺在SHOW INDEX FROM t结果里，持续吃掉I/O、内存和CPU，直到某次大促压垮写入链路才暴露。定期清理sys.schema_unused_indexes或用pt-duplicate-key-checker扫描，比盲目加索引重要得多。
