死锁日志中若显示 gen_clust_index 且 lock_mode x locks rec but not gap waiting，大概率因缺失有效索引导致全表扫描级加锁；慢查询中 rows_examined 远大于 rows_sent、explain 显示 type=all/key=null/extra=using filesort 也印证索引不足。
怎么看死锁日志里是不是索引缺失导致的
MySQL 的死锁信息本身不直接说“缺索引”，但会暴露关键线索：事务正在等待哪一行、加的是什么锁（lock_mode X locks rec but not gap）、扫描范围有多大（lock_trx_id 和 lock_row_id 配合看）、以及最关键的——是否在全表扫描或索引扫描后仍需回表查大量行。
重点看 WAITING FOR THIS LOCK TO BE GRANTED: 下面的 index 字段：如果显示 PRIMARY 或某个二级索引名，说明走了索引；如果显示 GEN_CLUST_INDEX（隐式聚簇索引），基本等于没走有效索引，正在做全表扫描级的加锁。
另外注意 lock_mode X locks rec but not gap waiting 出现的位置——如果两个事务都在等同一张表的同一范围，但执行计划里却没用上覆盖索引，大概率是索引设计没覆盖查询条件或 SELECT 列。
怎么从慢查询日志反推可能的死锁诱因
死锁未必出现在慢查询里，但长期执行、扫描行数多的语句更容易在并发下暴露索引缺陷。打开慢查询日志（slow_query_log = ON）后，重点关注 Rows_examined 远大于 Rows_sent 的语句，比如 Rows_examined: 124800 但 Rows_sent: 1，这说明 MySQL 扫了十多万行才找到 1 行——这种语句在高并发更新时极易因锁住过多记录引发死锁。
检查这类 SQL 的 WHERE 条件列是否建了索引，特别是组合条件（如 WHERE status = ? AND created_at > ?）是否命中最左前缀；也留意 ORDER BY 或 GROUP BY 列是否被索引覆盖，否则会触发 filesort + 全量加锁。
常见陷阱：
-
SELECT ... FOR UPDATE语句没走索引 → 锁整张表或大范围主键 - 使用函数包裹索引列：
WHERE DATE(created_at) = '2024-01-01'→ 索引失效 - 隐式类型转换：
WHERE user_id = '123'（user_id 是 INT）→ 索引可能不走
EXPLAIN 结果里哪些信号说明索引不够用
对疑似语句跑 EXPLAIN FORMAT=TRADITIONAL，盯紧这几项：
type 字段：值为 ALL（全表扫描）或 index（全索引扫描）是危险信号；理想是 range、ref、eq_ref。
key 字段：显示实际使用的索引名；如果是 NULL，说明没走索引；如果走了索引但 rows 值极大，说明索引区分度低或不是最优选择。
Extra 字段：出现 Using filesort 或 Using temporary 意味着无法利用索引完成排序/去重，往往伴随更大范围的锁持有时间。
特别注意：InnoDB 的 Next-Key Lock 会在范围查询时锁住间隙，如果 WHERE a > 100 没有索引，它就可能锁住整个主键范围——这时候看 EXPLAIN 的 rows 就知道影响面有多大。
补索引前必须验证的三件事
别一看到“没走索引”就加索引。先确认：
该 SQL 是否真的高频执行？低频语句加索引反而拖慢写入。
现有索引是否只是顺序不对？比如已有 (a, b)，而查询是 WHERE b = ?，那加 (b) 单列索引比加 (b, a) 更轻量。
新增索引会不会让 UPDATE/INSERT 变慢？尤其在写多读少的表上，每个索引都是额外的 B+ 树维护成本。
实操建议：用 pt-index-usage 或 sys.schema_unused_indexes（MySQL 8.0+）先看索引真实使用率；再用 ALTER TABLE ... ALGORITHM=INPLACE, LOCK=NONE 在从库验证索引效果，观察死锁频率是否下降。
真正难的不是加索引，是判断哪条路径上的锁范围正在被放大——有时候删掉一个冗余索引，反而让优化器选中更窄的扫描路径，死锁就少了。
