死锁检测是事务锁等待时实时触发的DFS遍历，非定时任务；每新增等待者即触发一次图构建与DFS，热点行上高并发等待导致CPU飙升；关闭检测仅延后超时回滚，加剧可用性与排障问题。
死锁检测不是定时任务，而是高频触发的DFS遍历
很多人以为innodb_deadlock_detect是后台悄悄跑的定时检查，其实它根本没“后台”——每次事务申请锁失败、进入等待状态时，InnoDB就立刻构建Wait-for Graph并执行一次深度优先遍历（DFS）来查环。这意味着：热点行上每多一个等待者，就多一次图构建 + DFS；100个事务卡在同一条记录上，就触发100次CPU密集型计算。
DFS本身时间复杂度在图稠密时接近O(N²)，而等待图节点数一旦超200，或单次需扫描锁超1,000,000个，InnoDB会直接放弃检测、回滚当前事务——这不是“检测完成”，而是“怕算太久”而提前投降。
- 高频触发的根源从来不是“检测逻辑写得差”，而是事务在热点行上反复撞锁
-
SHOW ENGINE INNODB STATUS里TRX HAS BEEN WAITING连续出现5条以上，且锁对象高度重复（如都卡在PRIMARY同一行），就是铁证 - 此时
BACKGROUND THREAD中Main thread state=sleeping，说明CPU真正在干“图遍历”，不是刷脏页或合并缓冲池
关掉innodb_deadlock_detect只会让问题更难发现
设innodb_deadlock_detect = OFF后，MySQL不再主动检测环，完全依赖innodb_lock_wait_timeout（默认50秒）超时回滚。这带来两个后果：
- 本该毫秒级识别并解决的死锁，变成最多50秒的无响应hang，连接池迅速被占满
-
SHOW ENGINE INNODB STATUS里LATEST DETECTED DEADLOCK段彻底消失，你只能看到一堆Lock wait timeout exceeded，根本看不出谁在等谁 - 应用层感知到的是“请求变慢+超时增多”，而不是“死锁报警”，根因定位难度指数级上升
这不是优化，是把CPU问题换成可用性问题和排障黑洞。
真正吃CPU的不是“检测”，是“不得不反复检测”
CPU飙升的表象下，本质是事务锁持有时间过长 + 访问顺序混乱，导致等待图持续膨胀。典型场景包括：
- Java事务里第一步就更新影院账户余额：
accountRepo.addBalance(cinemaId, amount)，按两阶段锁协议（2PL），这把锁要等到@Transactional方法结束才释放——整个事务周期都在持锁 - 全表扫描类SQL长时间持有S锁，后续UPDATE被阻塞，连锁触发大量检测
- AUTO_INC表级锁阻塞插入，引发长等待链，每个新插入请求都触发一次图更新+DFS
此时INFORMATION_SCHEMA.INNODB_TRX查询也会变慢，因为它底层共享同一套等待图内存结构——你连查问题都卡。
别调参数，先改代码和访问模式
所有靠SET GLOBAL innodb_lock_wait_timeout = 5或关检测的方案，都是在绕开症状。真正降CPU，必须让事务不进等待图：
- 把热点行操作挪到事务**最后**：先扣用户钱、再记日志、最后加影院余额，大幅缩短锁持有窗口
- 用
SELECT ... FOR UPDATE SKIP LOCKED跳过已锁行，避免排队等锁（适用于队列类场景） - 对影院账户做逻辑分片：
cinema_id % 4拆成4个子账户，写请求分散到不同物理行 - 余额类场景改用乐观锁：
UPDATE accounts SET balance = ? WHERE id = ? AND balance >= ?+ 应用层重试
最隐蔽的坑是：事务里混了网络I/O或慢RPC，人为拉长了锁生命周期——这点在监控里几乎不体现，但会让等待图爆炸式增长。
