InnoDB通过每次锁请求失败时触发等待图构建与DFS环检测来主动识别死锁，而非定时轮询；图更新含节点/边增删等开销，高并发热点争抢会导致CPU飙升、视图查询变慢，关闭检测仅用超时机制会加剧阻塞与定位难度。
Wait-for Graph 构建本身就有开销
每次事务请求锁失败、进入等待状态时，InnoDB 必须在内存中更新等待图：新增节点（事务）、添加有向边（A→B 表示事务 A 等待事务 B 持有的锁）。这个过程不是纯逻辑标记，而是涉及哈希表查找、链表插入、锁保护等操作。尤其当高并发下大量事务同时卡在同几行（比如热点账户余额），等待队列迅速膨胀，INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 视图的查询响应也会变慢——因为它们底层依赖同一套等待图数据结构。
环路检测是 CPU 密集型操作
MySQL 用深度优先遍历（DFS）检查等待图是否存在环。一旦等待图中事务数超过 200，或单个事务需扫描的锁数量超 1,000,000 个，InnoDB 会直接判定为潜在死锁并回滚当前事务——这不是检测出环，而是“怕检测太耗时”而提前放弃。这意味着：
- 等待图越大，DFS 遍历路径越长，CPU 占用越高
- 环不一定深，但图稠密（如 50 个事务互相部分等待）时，DFS 时间复杂度接近 O(N²)
- 检测不是定时轮询，而是**每次锁请求失败时触发**，所以高频争抢 = 高频 DFS
死锁检测不等于“只查一次”，它被高频触发
很多人误以为死锁检测是后台定时任务，实际上它是被动响应机制：只要一个事务在获取行锁时发现资源被占，且等待队列里已有其他等待者，就立刻启动图构建 + DFS。典型诱因包括：
-
SELECT ... FOR UPDATE LIMIT 1在任务队列场景中，所有线程都尝试锁第一行 → 全部排队 → 每个新请求都触发一次检测 - 大批量
INSERT使用默认innodb_autoinc_lock_mode = 1→ AUTO_INC 表级锁阻塞其他插入 → 形成长等待链 → 连锁触发检测 - 未加索引的
WHERE条件导致全表扫描+锁多行 → 事务持锁范围大，交叉等待概率飙升
关掉 innodb_deadlock_detect 不是优化，是掩盖问题
设 innodb_deadlock_detect = OFF 后，MySQL 不再主动检测环，而是完全依赖 innodb_lock_wait_timeout（默认 50 秒）超时回滚。这会导致：
- 本该毫秒级解决的死锁，变成最多 50 秒的无响应阻塞
- 连接池被占满、应用线程夯住、下游请求雪崩
-
SHOW ENGINE INNODB STATUS中不再出现Deadlock found when trying to get lock，但你会看到大量Lock wait timeout exceeded—— 更难定位根因
真正降低开销的方式不是关检测，而是让事务不进入等待图：用 SKIP LOCKED 跳过已锁行，或拆分热点更新，或用应用层分片避免多事务争同一行。
