MySQL死锁需定位预防而非修复，核心是用EXPLAIN分析type、key、rows三列以识别全表扫描、索引失效和预估偏差，确保UPDATE/DELETE走覆盖索引，事务中读写操作统一加锁并避免跨表依赖。
死锁不是能“解决”的，而是要定位+预防
MySQL死锁无法靠单条命令修复，它本质是事务竞争资源时的循环等待。你看到的 Deadlock found when trying to get lock 错误，只是系统主动杀掉其中一个事务的结果。真正要做的，是用 EXPLAIN 看清 SQL 实际怎么走索引、是否触发锁升级、有没有扫描全表——这些才是死锁温床。
EXPLAIN 要重点看这三列：type、key、rows
很多同学只扫一眼 EXPLAIN 输出就以为“用了索引”，其实关键在细节：
-
type是ALL或index？说明走了全表或全索引扫描，锁住的行远超预期，极易引发死锁 -
key显示的是哪个索引？如果为NULL，或者用了非唯一索引但WHERE条件不精确（比如模糊匹配、函数包裹字段），就会锁住多个间隙（gap lock） -
rows值是否远大于实际命中数？比如rows=10000但只更新 1 行，说明优化器预估严重偏差，很可能因统计信息过期或隐式类型转换导致
示例：EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND user_id = 123; 如果 type 是 ref 但 key 是 idx_status（仅含 status 的索引），那即使 user_id 有索引，也会锁住所有 status='pending' 的行——并发更新不同用户订单时，就容易形成 A 等 B、B 等 A 的局面。
UPDATE/DELETE 必须走覆盖索引，否则死锁概率飙升
MySQL 在执行 UPDATE 或 DELETE 时，如果不能仅靠索引完成条件判断和数据定位，就会先加记录锁（record lock），再加间隙锁（gap lock），最后可能升级成临键锁（next-key lock）。一旦涉及多行，顺序稍有不同，死锁就来了。
- 确保
WHERE条件中的字段组合有联合索引，且顺序匹配查询模式（如WHERE user_id = ? AND created_at > ?，索引应为(user_id, created_at)） - 避免在
WHERE中对字段做计算或类型转换，比如WHERE DATE(created_at) = '2024-01-01'会让索引失效 - 检查是否用了
OR拆分条件，MySQL 5.7+ 对简单OR可用 index merge，但容易导致锁范围不可控；优先改写为UNION ALL或补全索引
一个典型坑：UPDATE t SET state = 'done' WHERE id IN (SELECT id FROM t WHERE flag = 1) —— 子查询没走索引，外层 UPDATE 就可能锁住整张表，和另一条类似语句一撞就死锁。
事务里别混用 SELECT ... FOR UPDATE 和普通 SELECT
很多人以为“我只在关键步骤加锁就行”，结果在同一个事务里先执行了 SELECT * FROM accounts WHERE uid = 123;（没加锁），再执行 SELECT * FROM accounts WHERE uid = 123 FOR UPDATE;。这时第二条语句不仅要锁住记录，还可能因为第一次读没加锁、导致 MVCC 版本链变长，进而触发更宽的间隙锁——特别是当 uid 不是主键或唯一索引时。
- 所有需要后续修改的数据，第一次读就必须带
FOR UPDATE或LOCK IN SHARE MODE - 避免在事务中跨多个无关表查数据，尤其不要在查完 A 表后，再去查 B 表并基于 B 表结果更新 A 表——锁顺序难统一，死锁风险直线上升
- 如果必须读后再更新，确保两次操作之间没有其他事务插入符合 WHERE 条件的新行（否则 gap lock 范围会动态扩大）
最常被忽略的一点：autocommit=1 时，每个语句都是独立事务，SELECT ... FOR UPDATE 加的锁下一语句就释放了；而 autocommit=0 时，锁会一直持到 COMMIT 或 ROLLBACK。很多人没意识到自己其实在长事务里“裸奔”锁。
