mysql 8.0死锁检测更及时但开销略升，因后台线程持续维护等待图而非按需扫描；真正降低开销需避免触发检测，如用skip locked、乐观锁或拆分热点行，而非关闭innodb_deadlock_detect。
innodb_deadlock_detect 没有被“优化”，它只是默认保持开启，且底层等待图维护更持续——这不是为提速，而是为更快暴露问题。真正能降低死锁检测开销的，是避开检测触发条件，不是调参数。
死锁检测机制本身没变，仍是 wait-for graph
MySQL 8.0 和 5.7 都用相同的死锁检测原理：构建事务→锁的有向图，检测环。区别在于 8.0 默认启用后台线程持续追踪等待关系，而不是像 5.7 那样只在锁等待超时前临时扫描一次。这导致：
- 检测更及时：一旦形成环，几乎立刻回滚，不会拖到
innodb_lock_wait_timeout（默认 50 秒） - CPU 开销略升：持续维护图结构，尤其在高并发短事务场景下，线程数越多，图遍历越频繁
- 误报可能增多：更细粒度的等待链判断，会让某些边界竞争也被识别为死锁
真正减少检测开销的，是让检测根本不会启动
检测只在“事务尝试加锁失败 + 等待队列中已有其他等待者”时触发。所以降低开销的关键是避免进入这个路径：
-
SELECT ... FOR UPDATE SKIP LOCKED：跳过已被锁定的行，各事务操作不同记录，无等待、无图、无检测 -
innodb_autoinc_lock_mode = 2：批量插入不再持表级 AUTO-INC 锁，消除一大类锁等待源头 - 高频热点行更新改用应用层原子操作（如 Redis 计数器）或乐观锁（version 字段），绕过 InnoDB 行锁争抢
别关 innodb_deadlock_detect，关了只会让问题更难发现
设为 OFF 后，InnoDB 不再主动检测死锁，完全依赖 innodb_lock_wait_timeout 超时回滚。后果是：
- 用户请求卡住长达数十秒，而非秒级失败
-
SHOW ENGINE INNODB STATUS不再显示 DEADLOCK SECTION，日志里也看不到详细冲突链 - 应用层无法区分是真慢还是死锁，重试逻辑失效
除非你 100% 确认业务绝无循环等待可能（比如单线程写+无事务嵌套），否则关它是用隐蔽故障换表面稳定。
排查死锁必须用对视图和日志开关
MySQL 8.0 废弃了 INFORMATION_SCHEMA.INNODB_LOCK_WAITS，沿用老脚本会查不到实时锁等待：
- 查当前阻塞关系，必须用
performance_schema.data_lock_waits（需先启用events_transactions_currentconsumer） - 看完整死锁详情，必须同时开两个参数：
innodb_deadlock_detect = ON+innodb_print_all_deadlocks = ON - RDS 实例还需
log_error_verbosity = 3，否则堆栈不全
最容易被忽略的是：innodb_print_all_deadlocks 会持续刷盘，定位完问题务必关闭，否则磁盘 I/O 压力陡增。
