MySQL死锁需立即执行SHOW ENGINE INNODB STATUS\G定位LATEST DETECTED DEADLOCK段，提取(1)(2)事务的SQL、HOLDS与WAITING锁详情，并通过innodb_print_all_deadlocks持久化日志；根治关键在于统一加锁顺序、优化索引避免间隙锁、应用层指数退避重试。
MySQL生产环境报Deadlock found when trying to get lock错误，不是配置问题，也不是数据库坏了——它说明你的事务正在真实并发竞争资源。InnoDB已经检测并自动回滚了其中一个事务，但应用层若没处理这个错误码1213，就会直接抛异常、丢数据、触发告警。
怎么看死锁现场的原始日志？
别只看应用日志里的“Deadlock”字眼，必须立刻进数据库查真实上下文：
- 执行
SHOW ENGINE INNODB STATUS\G，滚动到------------------------ LATEST DETECTED DEADLOCK ------------------------段 - 重点抓两块：
(1) TRANSACTION和(2) TRANSACTION里各自的query id字段，它后面跟着的就是实际执行的SQL（不是ORM生成的伪SQL） - 注意看每个事务的
HOLDS THE LOCK(S)和WAITING FOR THIS LOCK TO BE GRANTED——哪个锁是记录锁（rec but not gap），哪个是间隙锁（gap before rec），锁在哪个索引上（index PRIMARYorindex idx_seller_id）
如果线上不敢频繁执行这个命令，就提前在my.cnf里打开持久化记录：innodb_print_all_deadlocks = 1，所有死锁都会追加到error.log里。
为什么统一SQL执行顺序能根治80%的死锁？
死锁本质是循环等待，而顺序不一致是最大诱因。比如两个事务都更新fund_transfer_stream和fund_transfer_order表，但A先改stream再改order，B反过来——只要并发一上来，必然撞上。
- 检查所有涉及多表/多行更新的业务代码，确认是否强制按同一物理顺序执行（例如：总是先
UPDATE fund_transfer_order，再UPDATE fund_transfer_stream） - 避免ORM自动生成SQL时条件顺序飘移（如MyBatis动态SQL中
<if>块顺序不固定），建议显式写死WHERE条件顺序 - 对单表多行更新，按主键升序排列ID再拼IN语句，例如把
WHERE id IN (105, 101, 103)改成WHERE id IN (101, 103, 105)，让不同事务锁定行的物理顺序一致
间隙锁（Gap Lock）怎么悄悄引发死锁？
在REPEATABLE READ隔离级别下，WHERE seller_id = ? AND state = 'NEW'这种等值查询本身不加间隙锁，但如果seller_id没索引，InnoDB会全表扫描，给所有扫描过的间隙都上锁；更常见的是WHERE id > 100这类范围查询，直接锁住(100, +∞)这个区间。
- 用
EXPLAIN确认出问题的SQL是否走了索引——type不能是ALL或index，key字段必须显示真实索引名 - 检查
fund_transfer_stream表上seller_id和state是否有联合索引，没有就建：ALTER TABLE fund_transfer_stream ADD INDEX idx_seller_state (seller_id, state) - 如果业务允许，可临时降级隔离级别为
READ COMMITTED（需评估幻读风险），它不使用间隙锁
应用层重试逻辑必须带退避，不能裸重试
捕获到1213错误后直接重试，可能瞬间压垮数据库——所有失败事务一起重试，形成“重试风暴”，死锁频率反而翻倍。
- Python示例中
time.sleep(0.1 * (attempt + 1))是关键：第1次重试等0.1秒，第2次等0.2秒，第3次等0.3秒，指数退避更稳妥 - 重试上限建议设为3次，超过就抛出明确业务异常（如
DeadlockRetryExhaustedError），由上游决定是否降级或告警 - 不要在事务内部做重试（比如MyBatis的
@Transactional方法里循环try-catch），每次重试必须是全新事务
真正难处理的从来不是死锁本身，而是那些没走索引的SQL、没约束顺序的批量更新、以及把网络IO塞进事务里的“长事务”。日志里看到ACTIVE 47 sec那种事务，比任何死锁都危险。
