调低 innodb_lock_wait_timeout 无法减少死锁，它只控制锁等待超时而非死锁检测；MySQL 8.0 死锁“变多”是因默认开启死锁检测，暴露了原本被忽略的环形等待；应分析死锁日志、统一索引访问顺序、清理僵尸事务。
别急着调 innodb_lock_wait_timeout，它解决不了死锁频率变高的根本问题——升级后死锁“变多”，其实是 MySQL 8.0 把原来被静默忽略的死锁全报出来了。
为什么调低 innodb_lock_wait_timeout 是错的方向
这个参数控制的是“等锁超时”，不是“死锁检测”。它只影响单个语句在等待锁时最多忍多久（默认 50 秒），超时后抛出 Lock wait timeout exceeded 错误，但事务本身不回滚，后续语句仍可能继续执行——这反而可能掩盖真实死锁，或引发更混乱的状态。
而你看到的高频 Deadlock found when trying to get lock（错误码 1213），是 innodb_deadlock_detect 触发的主动干预，和 innodb_lock_wait_timeout 无关。MySQL 8.0 默认开启该检测，所以原来 5.7 下没报的潜在环形等待，现在全暴露了。
- 调小它（比如设成 5 秒）只会让“锁等待失败”更频繁，但不会减少死锁发生次数，还可能把本可成功的小竞争也干掉
- 调大它（比如设成 120 秒）更危险：长等待会拖住连接、堆积阻塞、放大连锁反应，反而推高死锁感知密度
- 它无法改变两个事务加锁顺序冲突的本质，只是推迟或提前了失败时机
真正该检查的三个关键点
死锁日志里反复出现相同表、相同索引、不同执行顺序？说明应用层逻辑有问题，不是参数能救的。
- 用
SHOW ENGINE INNODB STATUS\G抽取LATEST DETECTED DEADLOCK区块，确认两个事务各自持有的锁（HELD LOCKS）和等待的锁（WAITING FOR THIS LOCK TO BE GRANTED）。重点看TABLE、INDEX、lock_mode和具体space id/page number/record - 检查所有涉及同一张表的写路径：是否都通过**同一个唯一索引字段**定位行（例如统一用
id，而不是有时用id、有时用order_no或user_id） - 查
information_schema.INNODB_TRX，找trx_started时间过早的事务——SELECT FOR UPDATE后没COMMIT或ROLLBACK的“僵尸事务”，是升级后最常被放大的隐患
如果非要调整 innodb_lock_wait_timeout，只在特定场景下考虑
它唯一合理的作用，是给那些明确知道“这里不该等太久”的业务路径设兜底，比如秒杀下单、支付回调这类强实时性操作。
- 仅对特定连接动态设置：
SET SESSION innodb_lock_wait_timeout = 10;，而非全局修改 - 必须配套应用层捕获
Lock wait timeout exceeded（错误码 1205），并做降级或重试，不能只靠数据库抛异常就完事 - 搭配
innodb_rollback_on_timeout = OFF（默认值），确保超时只中断当前语句，不意外回滚整个事务
真正卡住你的，从来不是那个 50 秒的等待阈值，而是事务里哪条 SQL 没走索引、哪个 RPC 调用拖住了锁、哪两段代码对同一组数据用了相反的访问顺序——这些细节，在 SHOW ENGINE INNODB STATUS 的锁堆栈里藏得最深，也最容易被跳过。
