大事务超时回滚本身不直接引发死锁，但会延长锁持有时间、增加循环等待概率；死锁由InnoDB毫秒级主动检测触发，非超时导致；应通过SHOW ENGINE INNODB STATUS和INNODB_TRX定位长事务，收缩事务边界、加覆盖索引、调低隔离级别来根治。
大事务超时回滚本身不会直接“引发”死锁，但它是死锁高发的温床——真正的问题是：事务还没来得及超时，就已经在等待锁时陷入循环依赖。MySQL 的 innodb_lock_wait_timeout 控制的是「等锁超时」（默认 50 秒），而 wait_timeout 或 interactive_timeout 控制的是「空闲连接超时」，两者常被混淆。死锁检测（innodb_deadlock_detect=ON）是毫秒级的，远快于任何超时机制，所以你看到的 ERROR 1213 (40001): Deadlock found when trying to get lock，几乎全是 InnoDB 主动检测并干掉的，不是超时触发的。
怎么快速确认是不是大事务导致的死锁
别猜，直接看现场证据：
- 执行
SHOW ENGINE INNODB STATUS;，重点找LATEST DETECTED DEADLOCK段落，里面会明确写出两个（或多个）事务各自持有的锁、等待的锁、SQL 语句和事务活跃时间（ACTIVE X sec）——如果看到某个事务ACTIVE 30 sec还在执行 UPDATE，基本就是它拖长了锁持有时间 - 查
information_schema.INNODB_TRX表，过滤长时间运行的事务：SELECT trx_id, trx_started, trx_state, trx_query FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - trx_started) > 10;，超过 10 秒就值得警惕 - 检查错误日志是否开启了
innodb_print_all_deadlocks = 1，没开就立刻加到my.cnf并重启，否则只留最近一次死锁，没法复盘规律
为什么“先回滚再重试”在大事务场景下不顶用
应用层捕获 ERROR 1213 后重试，对短事务有效；但对大事务，重试等于重复踩坑：
- 重试的 SQL 还是那几条，锁顺序没变、索引没加、外部调用还在事务里，第二次大概率再死锁
- 如果事务里有
SELECT ... FOR UPDATE+ 复杂计算 + 调用 HTTP 接口，重试只是把整个耗时流程再跑一遍，用户感知就是“点了两次下单，两次都失败” - 更危险的是：部分 ORM（如旧版 Django ORM）在重试时可能复用已部分执行的事务状态，导致数据不一致
真正能快速止血的三件事
不是改代码，而是先让线上稳住：
- 临时降低并发压力：比如电商下单接口加限流（如
redis.incr+ TTL），把 QPS 压到死锁不再爆发的阈值以下，抢出修复窗口 - 紧急收缩事务边界：把原事务中非数据库操作（日志记录、消息发送、第三方 API 调用）全挪到
COMMIT之后——哪怕多写一个异步任务队列，也比锁着库存表等短信网关响应强 - 给关键 UPDATE 加覆盖索引：死锁日志里如果出现
lock_mode X locks gap before rec，说明用了间隙锁，大概率是因为 WHERE 条件没走索引，赶紧补ALTER TABLE order ADD INDEX idx_user_status (user_id, status);
最容易被忽略的点：隔离级别和 autocommit
很多团队以为自己用的是 READ COMMITTED，其实连接池配置错了：
- 检查实际生效的隔离级别：
SELECT @@tx_isolation;，不是看配置文件，是看当前会话值 - 确认应用没关
autocommit：有些框架（如老版本 SQLAlchemy）默认autocommit=False，结果一个简单INSERT也自动开启事务，锁一直挂着 -
REPEATABLE READ下的间隙锁是死锁大户，除非业务强依赖可重复读语义，否则直接在连接字符串里加?sessionVariables=tx_isolation=READ-COMMITTED
死锁不是故障，是并发逻辑的显影液。大事务暴露的从来不是 MySQL 的问题，而是业务代码里那些“顺手塞进事务”的网络 IO、循环遍历、条件分支——这些地方不清理，加再多监控也没用。
