死锁检测会显著消耗CPU，尤其在高并发热点行更新时；InnoDB在每个DML语句前全量遍历等待图，复杂度随活跃事务数和锁链长度上升，导致CPU飙升。
死锁检测本身就会吃 CPU，尤其在高并发热点行更新时
MySQL 的死锁检测不是“按需触发”的低开销操作，而是每个 INSERT/UPDATE/DELETE 语句执行前，InnoDB 都会检查当前事务等待图（wait-for graph）是否存在环。这个检查是全量遍历，复杂度和活跃事务数、锁等待链长度强相关。当出现大量事务卡在同一条热点行（比如账户余额、库存计数器）上排队时，检测开销会指数级上升——你看到的 CPU 100%，往往不是 SQL 执行慢，而是死锁检测在疯狂循环扫描。
典型现象包括：
-
SHOW ENGINE INNODB STATUS中频繁出现*** (1) WAITING FOR THIS LOCK TO BE GRANTED:和*** (2) HOLDS THE LOCK(S):交替刷屏 -
innodb_row_lock_waits持续上涨，但innodb_row_lock_time_avg并不高（说明不是锁持有久，而是反复抢锁失败重试） - 应用层报错以
Deadlock found when trying to get lock为主，且集中在少数几张表的少数几个主键值上
innodb_deadlock_detect 关闭后，死锁不会自动解决，但 CPU 会立刻回落
这个参数控制 InnoDB 是否启用死锁检测逻辑。设为 OFF 后，InnoDB 不再主动扫描等待图，自然不再消耗 CPU 做检测。但它不等于“没有死锁”，而是把死锁退化成“无限等待”：事务会一直卡在 LOCK WAIT 状态，直到超时（由 innodb_lock_wait_timeout 控制，默认 50 秒）后被强制回滚。
是否能关？取决于业务容忍度：
- 允许部分请求延迟 50 秒再失败 → 可关，适合非实时核心路径（如日志写入、异步任务触发）
- 要求快速失败（比如支付扣款必须秒级响应）→ 必须开，否则用户会卡住等半分钟才被告知失败
- 已用应用层重试 + 降级兜底 → 关比开更稳，避免 CPU 雪崩拖垮整个实例
临时关闭命令：SET GLOBAL innodb_deadlock_detect=OFF;；持久化需写入 my.cnf 的 [mysqld] 段落。
关掉死锁检测 ≠ 解决根本问题，只是掩盖症状
真正导致死锁高频发生的，从来不是检测机制本身，而是 SQL 访问顺序不一致 + 热点行集中。例如两个事务同时更新用户 A 和用户 B 的余额，一个按 UPDATE ... WHERE id IN (1001, 1002)，另一个按 UPDATE ... WHERE id IN (1002, 1001)，就极易形成环路。检测关了，这种冲突依然存在，只是从“10ms 报错”变成“50s 后超时回滚”。
比开关参数更有效的做法：
- 所有涉及多行更新的 SQL，强制按主键升序排列条件（如用
ORDER BY id或应用层排序后再拼 IN） - 把热点行拆分成逻辑分片（如账户余额按 user_id % 16 分桶），分散锁竞争
- 用
SELECT ... FOR UPDATE NOWAIT替代阻塞式加锁，让应用自己决定重试或跳过 - 确认隔离级别：若业务允许，将
REPEATABLE READ降为READ COMMITTED，可消除间隙锁带来的额外死锁风险
高并发下开关参数的真实性能差异，看监控指标比看文档更准
官方文档说关掉 innodb_deadlock_detect 能“显著降低开销”，但实际影响因场景而异。我们在线上压测过同一套电商秒杀逻辑：
- 开启检测（默认）：QPS 800 时 CPU 达 92%，死锁报错率 3.7%
- 关闭检测：QPS 800 时 CPU 降至 41%，但
innodb_lock_wait_timeout触发的超时回滚升至 12.4%，平均响应延迟从 45ms 拉长到 2.1s
结论很实在：它不是“开好还是关好”的二选一，而是“你要确定性失败，还是要可控延迟”。别只盯着 CPU 数字，Threads_running、Innodb_row_lock_time、应用层 P99 延迟这三项必须一起看。最容易被忽略的是——一旦关了检测，SHOW ENGINE INNODB STATUS 里就再也看不到死锁详细 trace 了，排查问题会变困难。
