死锁检测默认开启且不应关闭，关闭会导致死锁等待超时（默认50秒）而非快速失败；死锁增多主因是业务逻辑、索引缺失或加锁顺序不一致，而非检测机制本身。
死锁检测默认是开的，关它没意义还危险
MySQL 的 innodb_deadlock_detect 默认值就是 ON，InnoDB 本身必须靠它来发现循环等待并主动回滚事务。关掉它不会“提升性能”，只会让死锁卡住直到锁超时（innodb_lock_wait_timeout，默认 50 秒），用户看到的是长达几十秒的假死，而不是快速失败。
常见错误现象：
• 应用层报错突然变少，但大量请求在 UPDATE 或 SELECT ... FOR UPDATE 上 hang 住
• SHOW ENGINE INNODB STATUS 里看不到最近的 DEADLOCK 记录，但 TRANSACTIONS 列表里一堆 waiting for lock
- 只在极特殊场景（如已确认无任何循环依赖、且能接受锁超时 fallback）才考虑关，生产环境不建议碰
- 关的命令是
SET GLOBAL innodb_deadlock_detect=OFF，但需要 SUPER 权限，且重启后失效 - 关掉后，死锁不再被主动检测，InnoDB 退化为纯超时机制，响应延迟不可控
高并发下死锁多，不是检测慢，是业务逻辑容易触发循环等待
死锁数量上升，99% 和 innodb_deadlock_detect 的开关无关，而是因为并发写入路径变多、事务粒度变粗、或行锁升级成间隙锁（Gap Lock）导致锁范围意外扩大。
典型使用场景：
• 多线程批量插入/更新同一张表，且 WHERE 条件未走索引（触发全表扫描+间隙锁）
• 按不同顺序访问相同几行（比如事务 A 先更新 id=1 再更新 id=2，事务 B 反过来）
• 使用 SELECT ... FOR UPDATE 但没加 ORDER BY，导致各事务加锁顺序不一致
- 优先检查执行计划：确保所有
FOR UPDATE/UPDATE的 WHERE 都命中索引，避免间隙锁扩散 - 统一 DML 加锁顺序：比如固定按
id ASC排序后再批量处理，用SELECT ... ORDER BY id FOR UPDATE - 缩短事务生命周期：把非数据库操作（如 HTTP 调用、计算）挪到事务外，减少持锁时间
想“优化”死锁检测，其实是在优化锁行为本身
innodb_deadlock_detect 本身开销极低（只是检查等待图是否有环），真正吃 CPU 的是锁冲突频繁导致的反复检测+回滚+重试。所谓“优化检测”，本质是降低冲突概率。
参数差异与影响：
• innodb_deadlock_detect=ON：每次加锁前检查环，开销可忽略（纳秒级），但高频冲突会放大事务失败率
• innodb_deadlock_detect=OFF：加锁不检查，只等超时；锁等待期间线程不释放 CPU，可能堆积大量 sleeping 线程
- 不要调
innodb_rollback_on_timeout来“配合”关检测——它只控制单语句超时是否回滚整个事务，和死锁无关 - 监控重点应是
Innodb_row_lock_waits和Innodb_deadlocks状态变量，而非检测开关本身 - 如果每秒死锁数 > 1，先看
SHOW ENGINE INNODB STATUS里的 LATEST DETECTED DEADLOCK，定位具体 SQL 和索引使用问题
真正该关的不是死锁检测，是自增锁争用或唯一键检查
某些高并发插入场景下，用户误以为“死锁多是因为检测太勤”，实际根因是 innodb_autoinc_lock_mode=0（传统模式）或唯一约束校验引发的隐式锁竞争。这些比死锁检测本身更容易成为瓶颈。
容易踩的坑：
• 用 INSERT ... SELECT 批量导入时，autoinc_lock_mode=0 会导致表级自增锁，所有插入串行化
• INSERT IGNORE / REPLACE INTO 在唯一键冲突时会加 GAP 锁，且不释放，极易和其他事务形成死锁链
- 设为
innodb_autoinc_lock_mode=2（交错模式），前提是 binlog_format=ROW - 避免在高并发路径上用
INSERT IGNORE做“存在性判断”，改用先SELECT再INSERT（配合唯一索引+重试） - 检查是否无意中建了多个重复的唯一索引，导致每次写都要校验多遍
死锁检测这层逻辑很薄，真正厚的是你的 SQL 访问模式和索引设计。盯着开关调，不如花十分钟看一眼 SHOW CREATE TABLE 和慢查里的执行计划。
