MySQL死锁是事务并发时资源竞争的必然结果，由互斥、持有并等待、不可抢占、循环等待四个条件共同引发；InnoDB自动检测并回滚代价小的事务，抛出1213错误；最常见诱因是多事务对同一组行以不同顺序加锁，如转账中A先更新id=1再id=2、B反之，形成闭环等待；间隙锁、索引缺失、ORM隐式SQL、批量与单行操作混用等均会加剧风险；排查首选SHOW ENGINE INNODB STATUS查看LATEST DETECTED DEADLOCK；预防核心是显式SELECT ... FOR UPDATE一次性锁定、缩短事务、确保索引命中、合理设置隔离级别与锁超时。
MySQL死锁不是配置错误或版本缺陷，而是事务并发执行时资源竞争的必然结果——只要满足互斥、持有并等待、不可抢占、循环等待四个条件，死锁就可能发生。InnoDB 检测到后会主动回滚代价小的事务，并抛出 Deadlock found when trying to get lock 错误。
死锁最常发生在 UPDATE 顺序不一致时
两个事务修改同一组行，但加锁顺序相反，是最典型的死锁诱因。比如转账场景中，事务 A 先更新 id=1 再更新 id=2，而事务 B 反过来先更新 id=2 再更新 id=1，就会形成 A 等 B 的锁、B 等 A 的锁的闭环。
- 即使只操作一张表，只要 WHERE 条件顺序或索引扫描路径不同（例如一个走主键，一个走二级索引），InnoDB 加锁顺序也可能不同
- ORM 自动生成 SQL 时，
WHERE子句字段顺序不固定，容易隐式导致加锁顺序混乱 - 批量更新（
UPDATE ... WHERE id IN (2,1)）和单行更新（UPDATE ... WHERE id = 1）并发时，InnoDB 对IN列表的处理顺序未必与传入顺序一致，需依赖索引结构
间隙锁（Gap Lock）在 RR 隔离级别下极易引发死锁
REPEATABLE READ 是 InnoDB 默认隔离级别，它会使用 Next-Key Lock（记录锁 + 间隙锁），防止幻读。但这也意味着：即使你更新的是不存在的记录，只要落在某个索引间隙内，也会被锁住。
- 例如表中有
id值为 10 和 20，执行UPDATE t SET x=1 WHERE id = 15（无此行），InnoDB 会锁住间隙(10,20)；此时另一个事务插入id=15或更新id=18，就可能触发死锁 - 唯一索引上的等值查询（
WHERE id = ?）不会加间隙锁，但范围查询（WHERE id > 10）一定会 - 联合索引中，如果
WHERE只用了前导列（如索引是(a,b)，但只写WHERE a = 1），仍会加间隙锁
SHOW ENGINE INNODB STATUS 是排查死锁的第一现场
这个命令输出里 LATEST DETECTED DEADLOCK 区域，就是 MySQL 自动捕获的最近一次死锁快照，比应用日志更权威、更完整。
- 重点看两段事务的
TRANSACTIONID、mysql thread id和最后执行的SQL - 注意每条语句后面标注的锁类型：
X（排他锁）、S（共享锁）、GAP（间隙锁）、NK（Next-Key） - 检查是否走了预期索引：如果显示
table scan或index scan范围过大，说明缺失索引，导致锁升级 - 临时开启全量死锁日志：
SET GLOBAL innodb_print_all_deadlocks = ON，避免只保留最后一次
预防比处理更重要，但不能只靠“统一顺序”
单纯要求所有事务按 ID 升序更新，看似简单，实际在复杂业务中很难落地——比如订单要先锁用户再锁商品，而库存服务又要先锁商品再锁仓库，跨系统协调成本极高。
- 真正可控的防线是：用
SELECT ... FOR UPDATE提前、显式、一次性锁住所有待更新行，且 WHERE 条件必须命中索引，避免锁扩大 - 缩短事务生命周期：把网络调用、日志打印、复杂计算等非数据库操作移出事务块，减少锁持有时间
- 必要时降级隔离级别：将 RR 改为
READ COMMITTED可彻底关闭间隙锁，但需确认业务能接受不可重复读 - 最易被忽略的一点：
innodb_lock_wait_timeout默认是 50 秒，线上应设为 5–10 秒，避免一个慢事务拖垮整个连接池
