关闭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 全耗在分析依赖关系上了。
关之前必须满足三个硬性条件
缺一不可，否则不是优化，是埋雷：
- 所有写操作严格按**固定顺序加锁**：比如总是先更新
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 = 5runtime 生效） - 应用层必须捕获
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 日志闭环、没在应用层实现可靠重试，就别碰这个开关。
