关闭innodb_deadlock_detect仅当检测本身成CPU瓶颈时：perf显示lock_deadlock_check等函数CPU占比超15%且Innodb_deadlocks≥20/秒；须严格满足三条件——固定加锁顺序、主键升序更新、innodb_lock_wait_timeout设5–10秒并应用层指数退避重试；同时必开innodb_print_all_deadlocks、监控行锁等待指标、保持innodb_rollback_on_timeout=OFF，并警惕等待线程持续占用CPU。

只在死锁检测本身成为CPU瓶颈时才关

关 innodb_deadlock_detect 不是为了“避免死锁”，而是为了解决检测逻辑反成性能拖累的问题。典型信号是：perf top -p $(pgrep mysqld) 显示 lock_deadlock_check 或 row_sel_get_clust_rec_for_mysql 占用 CPU 持续超 15%；同时 SHOW GLOBAL STATUS LIKE 'Innodb_deadlocks' 每秒返回值 ≥ 20。这说明不是业务逻辑有死锁，而是大量短事务（如秒杀扣库存）反复争抢同一行，导致 InnoDB 每次加锁都要遍历越来越大的等待图——复杂度接近 O(N²)，CPU 全耗在分析依赖关系上了。

关之前必须满足三个硬性条件

缺一不可，否则不是优化，是埋雷：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 所有写操作严格按**固定顺序加锁**：比如总是先更新 orders 再更新 inventory；同一表内更新必须按主键升序（WHERE id IN (1,3,2) 要重写为 WHERE id IN (1,2,3)）
• innodb_lock_wait_timeout 必须设为 5–10 秒（不能只改配置文件，要 SET GLOBAL innodb_lock_wait_timeout = 5 runtime 生效）
• 应用层必须捕获 Lock wait timeout exceeded 错误，并做指数退避重试（最多 3 次），不能当成“失败”直接丢弃

关之后必须同步调整的参数和监控项

单独设 innodb_deadlock_detect=OFF 是危险操作：

• 必须开启 innodb_print_all_deadlocks=ON：即使检测关了，InnoDB 在超时前仍会尝试检测并记日志，这是你唯一能回溯死锁现场的途径
• 必须监控 Innodb_row_lock_waits 和 Innodb_row_lock_time_avg：若后者持续 > 100ms，说明锁竞争已失控，得立刻回退
• innodb_rollback_on_timeout 必须保持 OFF（默认值）：它控制超时后是回滚语句还是整个事务；设为 ON 会导致事务状态不一致，应用难以判断是否该重试

最容易被忽略的副作用：等待线程不释放CPU

关掉检测后，事务不再被主动回滚，而是卡在 LOCK WAIT 状态等超时。此时线程仍是 active 状态，持续占用 CPU 调度资源，SHOW PROCESSLIST 里会出现大量 updating 或 Locked 的 sleeping 线程——它们没在干活，但也没让出 CPU。这不是“省资源”，是把 CPU 开销从“检测”转移到了“空等”。没有压测过并发连接数、没验证过 error log 日志闭环、没在应用层实现可靠重试，就别碰这个开关。