innodb_lock_wait_timeout不是死锁超时参数，仅控制锁等待放弃时间；死锁由innodb_deadlock_detect实时检测并毫秒级处理，报错ERROR 1205需通过SHOW ENGINE INNODB STATUS确认是否真死锁。
innodb_lock_wait_timeout 不是死锁超时参数，它不控制死锁检测，只控制“等锁多久就放弃”。MySQL 中没有“死锁超时”这个概念——死锁由 innodb_deadlock_detect 实时触发，毫秒级响应，无需设超时。
看到报错 ERROR 1205 (40001)，第一反应别急着调 innodb_lock_wait_timeout。先确认是不是真死锁：运行 SHOW ENGINE INNODB STATUS，看 LATEST DETECTED DEADLOCK 小节。如果那里有两事务互相持锁的日志，才是死锁；如果只有单条等待记录、且没循环依赖，大概率是锁等待超时（也报 ERROR 1205，但成因不同）。
为什么改 innodb_lock_wait_timeout 解不了死锁问题
死锁检测机制独立于该参数，由 InnoDB 内核自动完成，不依赖等待时长。你把 innodb_lock_wait_timeout 从 50 改成 5 秒，死锁照样会在 1 毫秒内被发现并杀掉一个事务。
- 设小了（如 5 秒）：正常锁竞争被误判为“等太久”，频繁报 ERROR 1205，重试压力陡增
- 设大了（如 300 秒）：掩盖真实锁争抢——不是死锁变多了，而是“卡住但还没超时”的事务在日志里藏得更深
-
innodb_deadlock_detect = ON（默认）时，根本不存在“死锁超时”这个调节项
真正该查的：谁在持锁不放
死锁频发，90% 源头是长事务或未走索引的 DML。重点盯这些：
- 执行
SELECT * FROM information_schema.INNODB_TRX WHERE TIME_TO_SEC(NOW() - TRX_STARTED) > 60，找运行超 1 分钟的事务 - 对疑似 SQL 跑
EXPLAIN，确认UPDATE/DELETE是否命中索引，避免type: ALL触发全表间隙锁 - 检查应用层是否在事务里做了 HTTP 调用、文件读写等非 DB 操作，导致事务实际持锁时间远超预期
OLTP 场景下 innodb_lock_wait_timeout 的合理值
这不是“死锁设置”，而是“让等待失败得更及时”的折中点：
- 普通订单/支付接口：设为
15—— 足够覆盖网络抖动，又不至于拖垮线程池 - 已集成幂等重试（如 Spring Retry）的服务：可放宽到
25，给重试留缓冲 - 秒杀类库存扣减：设为
5～10，逻辑极简+竞争激烈，快速失败比硬等更稳 - 绝对不要设为
0：官方明确不推荐，等于无限等待，极易引发连接堆积
调参只是暴露问题的探针，不是解药。锁等待超时报错背后，永远是没提交的事务、没加的索引、或没拆开的业务逻辑。
