update多导致索引变慢，因需同步维护b+树索引，引发页分裂、刷脏、唯一校验及锁争抢；应优化索引设计、启用change_buffering、避免全表扫描更新、合理使用upsert与锁策略。
为什么 UPDATE 一多，索引就变慢？
因为 MySQL 在更新带索引的字段时，不仅改数据行，还要同步维护 B+ 树索引结构——尤其是二级索引，每次 UPDATE 都可能触发页分裂、缓冲池刷脏、甚至唯一性校验。高并发下这些操作争抢 index latch 和 buffer pool mutex，锁等待直接堆起来。
实操建议：
- 避免在
WHERE条件里用非索引字段更新索引字段（例如UPDATE t SET status=1 WHERE name='xxx'，而name没索引）——会全表扫描+逐行更新索引，锁住整张表 - 把高频更新的列和查询条件列拆开：比如
status经常变，但created_at几乎不变，就别把它们塞进同一个联合索引 - 确认
innodb_change_buffering开启（默认是all），它能缓存非唯一二级索引的更新，减少随机 IO —— 但只对离散更新有效，批量顺序写反而可能降低收益
INSERT ... ON DUPLICATE KEY UPDATE 的锁范围比你想的大
这个语法看着像“存在就改，不存在就插”，实际执行时，InnoDB 会对 INSERT 尝试路径上的所有间隙（gap）加 INSERT_INTENTION 锁，并对命中记录加 X 锁。如果唯一索引冲突频繁，很容易卡在间隙锁等待上。
常见错误现象：Deadlock found when trying to get lock; try restarting transaction，尤其出现在按时间戳或自增 ID 批量 upsert 场景。
实操建议：
- 确保冲突判断字段是
UNIQUE或PRIMARY KEY，否则会退化成全表扫描+行锁 - 批量操作时，按主键升序排序后再提交，减少间隙锁交叉（例如先处理
id=100，再id=200，而不是反过来） - 若只是想避免重复插入，且不关心是否真更新了，用
INSERT IGNORE更轻量——它遇到唯一冲突直接跳过，不加 X 锁
什么时候该删掉二级索引？
不是所有 WHERE 条件都值得建索引。每多一个二级索引，INSERT/UPDATE/DELETE 就得多维护一棵树；更麻烦的是，MySQL 优化器可能因索引太多选错执行计划，反而让 UPDATE 变慢。
使用场景判断：
- 单列索引只被用于等值查询（
=），且该列更新频率 > 查询频率 → 删 - 联合索引中，左边字段区分度极低（如
(is_deleted, user_id)，is_deleted只有 0/1）→ 考虑改成(user_id, is_deleted)或直接删 -
SELECT COUNT(*) FROM t WHERE x=1这类查询，如果x更新极频繁，又没其他查询依赖该索引，不如用覆盖索引 + 快照统计替代
innodb_lock_wait_timeout 调小并不能解决根本问题
很多人一看到 Lock wait timeout exceeded 就立刻把 innodb_lock_wait_timeout 从 50 改成 5，以为能“快速失败”。其实这只是让事务更快报错，锁冲突本身还在——下游重试逻辑没跟上的话，QPS 一高照样雪崩。
真正要盯的是锁等待链源头：
- 用
SELECT * FROM information_schema.INNODB_TRX查长时间运行的事务 - 结合
INNODB_LOCK_WAITS和INNODB_LOCKS（MySQL 5.7+ 已废弃，用performance_schema.data_locks替代）定位谁在等谁 - 检查是否有长事务没提交（比如应用层开了事务但忘了
COMMIT），或者大事务在做UPDATE时锁住了热点行
索引更新的瓶颈往往不在 SQL 写法，而在数据分布和事务边界——比如一个订单状态流转，把“支付中→已支付”和“已支付→已发货”放在两个事务里，比塞在一个事务里锁得轻得多。
