可通过执行 show engine innodb status\g 查看 latest detected deadlock 区块获取最近一次死锁的完整现场，包括事务持有的锁、等待的锁、sql 语句、事务 id 及行记录位置等关键信息。
怎么看当前有没有死锁发生
MySQL 里死锁不是“发生了就报错”，而是被自动检测并回滚其中一个事务，所以你可能只看到 Deadlock found when trying to get lock 这种错误，却不知道谁和谁在争什么。关键不是等报错，而是主动查。
实操建议：
- 执行
SHOW ENGINE INNODB STATUS\G，重点看LATEST DETECTED DEADLOCK区块，它会给出最近一次死锁的完整现场：两个事务各自持有的锁、等待的锁、SQL 语句、事务 ID、甚至行记录的space id和page number - 注意时间戳——这个区块只保留最后一次死锁，不是历史日志。如果死锁频发，得配合监控或开启
innodb_print_all_deadlocks = ON把所有死锁写进 error log - 别只盯着 SQL 文本，要看
WAITING FOR THIS LOCK TO BE GRANTED和HOLDS THE LOCK(S)的对应关系，这才是冲突根源
为什么 UPDATE 多行时特别容易死锁
不是语句本身有问题，而是 InnoDB 加锁顺序和索引扫描路径共同导致的竞态。比如两个事务按不同顺序更新同一组主键，就可能形成环路。
常见错误现象：
- 事务 A 执行
UPDATE t SET x=1 WHERE id IN (10, 20)，按主键升序加锁（10 → 20） - 事务 B 同时执行
UPDATE t SET x=2 WHERE id IN (20, 10)，但优化器仍按升序扫描（10 → 20），实际加锁顺序却受执行时机影响，可能先锁 20 再锁 10 - 结果就是 A 持有 10 等待 20，B 持有 20 等待 10 —— 死锁成立
实操建议：
- 批量更新务必按主键（或唯一索引）**严格升序**组织条件值，例如用
ORDER BY id配合子查询或应用层排序 - 避免在同一个事务里混用不同索引条件更新同一张表，比如先用
WHERE status=1更新，再用WHERE id IN (...)更新，锁范围和顺序更难预测 - 如果业务允许，考虑拆成单条
UPDATE并加FOR UPDATE显式控制，虽然吞吐下降，但锁行为可预期
如何用 SELECT ... FOR UPDATE 规避死锁但不卡住别人
SELECT ... FOR UPDATE 不是万能锁，它加的是 next-key lock，范围可能比你想象的大。用不好反而扩大锁冲突面。
使用场景：
- 读取后必更新的场景，比如“查余额 → 判断是否足够 → 扣款”，必须保证读到的值没被其他事务改过
- 需要跨多行做一致性判断时，比如库存扣减前检查多个 SKU 是否都充足
参数差异与坑点：
- 没有
WHERE条件时，SELECT * FROM t FOR UPDATE会锁全表（准确说是锁所有索引记录 + 间隙），千万别在线上这么干 - 用非唯一索引查询时，InnoDB 会锁住满足条件的所有记录 + 相邻间隙（防止幻读），即使你只想要其中一行
- 如果
WHERE条件命中唯一索引且返回单行，那锁粒度就是该行 record lock，最安全；否则优先改用唯一键查询
死锁日志里看到 lock_mode X locks rec but not gap 是什么意思
这是 InnoDB 锁类型的关键标识，直接决定是否阻塞插入新记录。很多人以为 X 就是“排他锁”完事了，其实后面跟的 rec 或 gap 才决定影响范围。
说明：
-
lock_mode X locks rec but not gap：只锁记录本身，不锁间隙。适用于唯一索引精确匹配（如WHERE id = 100），此时不会阻止INSERT INTO t VALUES (99)或(101) -
lock_mode X locks gap before rec：只锁间隙，不锁记录。常见于WHERE id > 100且无记录匹配时，防止其他事务插入满足条件的新行 -
lock_mode X locks rec but not gap看似安全，但如果事务里后续又执行了范围扫描（比如WHERE id > 100），可能升级为 next-key lock，之前“松”的锁就变紧了
容易被忽略的地方：死锁图里两个事务的 lock mode 可能不同，一个锁 record，另一个锁 gap，但因为间隙和记录在逻辑上相邻，照样能构成循环等待。不能只看有没有 X，得看锁住了什么、在哪里。
