索引越多事务写入越慢，因需同步更新所有索引并引发树分裂、页合并等开销；唯一索引锁单行，普通索引易触发间隙锁扩大阻塞；联合索引顺序不当、隐式临时表等均会拖慢事务。
索引越多，事务写入越慢
事务中涉及 INSERT、UPDATE、DELETE 时，每条语句不仅要修改数据页，还要同步更新所有相关索引。每个二级索引都是独立的 B+ 树，插入一行就可能触发多次树分裂、页合并和缓冲池刷脏。实测表明：在高并发写入场景下，单表从 1 个索引增加到 5 个，UPDATE 平均延迟可上升 3–8 倍（取决于字段长度和索引选择性）。
常见错误现象包括：
- 事务执行时间不稳定，偶发超时（
Lock wait timeout exceeded） -
SHOW PROCESSLIST中大量线程卡在updating或waiting for handler commit - 磁盘 I/O 持续跑满，
Innodb_buffer_pool_wait_free计数明显上升
唯一索引与普通索引对事务锁的影响不同
MySQL 在加锁时会根据索引类型决定锁范围。使用唯一索引（含主键）定位记录，InnoDB 通常只加 record lock；而普通索引 + WHERE 条件匹配多行时，可能升级为 gap lock 或 next-key lock，扩大锁粒度，加剧事务阻塞。
典型场景：
-
UPDATE t SET status=1 WHERE order_no='ORD123'（order_no是唯一索引）→ 锁单行 -
UPDATE t SET status=1 WHERE create_time > '2024-01-01'（create_time是普通索引）→ 可能锁住整个范围，阻塞其他插入 - 在 RC 隔离级别下，普通索引仍可能引发间隙锁，尤其配合
SELECT ... FOR UPDATE时
联合索引顺序不当会拖慢事务中的点查与范围查
联合索引遵循最左前缀原则，但事务里常混用多种查询模式。比如建了 (a, b, c) 却频繁执行 WHERE b = ? AND c = ?，导致索引失效，被迫走全表扫描或临时文件排序——这不仅拉长单条 SQL 时间，还会延长事务持有锁的时长，提高死锁概率。
优化建议：
- 按事务内实际
WHERE条件出现频率和选择性排序字段，高频等值条件放最左 - 把经常用于排序或分组的字段放在最后（如
(user_id, status, created_at)支持WHERE user_id=? AND status=? ORDER BY created_at DESC） - 避免在事务关键路径中依赖
LIKE '%xxx'或函数索引（如UPPER(name)），它们无法利用 B+ 树有序性
事务中隐式创建临时索引会彻底破坏性能
某些 ORM 或中间件在事务内动态拼接 SQL，触发 MySQL 自动生成内部临时表（Using temporary; Using filesort）。这类临时结构不走缓冲池，全靠磁盘和内存排序，且无法复用。更麻烦的是：如果事务中途失败回滚，这些临时资源释放不及时，可能污染后续事务的执行计划缓存。
识别方式：
- 开启
slow_query_log并设置long_query_time=0，抓取事务内慢 SQL - 检查
EXPLAIN输出中是否含Using temporary或Using filesort - 监控
Created_tmp_disk_tables增速是否与事务量正相关
真正难处理的是那些“看起来合理”的索引——比如为加速日志归档加的冗余索引，在低频读场景下没问题，一旦接入实时对账任务，就会在事务链路里悄悄放大延迟。索引不是越多越好，而是要贴着事务的锁范围、执行路径和回滚段压力去设计。
