innodb强制启用死锁检测，innodb_deadlock_detect不可关闭；检测仅在锁等待时按需触发，优化关键在于减少冲突和单次开销，而非调整频率。
死锁检测是默认开启的，innodb_deadlock_detect 不能设为 OFF
MySQL 8.0.24 之前，innodb_deadlock_detect 是只读变量，根本不能改；之后虽支持动态设置，但设成 OFF 会直接报错：ERROR 1238 (HY000): Variable 'innodb_deadlock_detect' is a read only variable。InnoDB 强制启用死锁检测——它没有“关闭”这个选项。
你真正能调的，其实是死锁检测的触发时机和代价控制，不是“开/关”本身。
实际影响性能的是死锁检测的代价，不是“频率”
InnoDB 没有“每 X 秒检测一次”的轮询机制。死锁检测只在事务尝试加锁失败（比如等 LOCK_WAIT）时才触发，属于按需、即时检测。所谓“频率”，本质是并发冲突多不多、锁等待链长不长。
- 高并发短事务 + 大量行锁竞争 → 触发检测更频繁，且单次检测开销更大（要遍历等待图）
- 用
SELECT ... FOR UPDATE锁住无关行、或锁顺序不一致 → 极易构造环，让检测更常跑、更慢 -
innodb_deadlock_detect = ON是唯一合法值，但检测过程本身会阻塞其他线程获取同一锁资源，形成“检测反压”
降低死锁检测开销的实操办法
与其纠结“怎么调频率”，不如减少检测被触发的次数和单次成本：
- 统一 SQL 中的锁顺序：比如所有业务都先更新
user表再更新order表，避免循环等待 - 减少锁持有时间：把非数据库操作（如 HTTP 调用、计算）移到事务外；避免在事务里做 sleep 或用户输入等待
- 用
SELECT ... LOCK IN SHARE MODE替代不必要的FOR UPDATE，降低锁粒度和冲突概率 - 对热点行，考虑拆分（如用哈希分片）、或改用乐观锁（
version字段 +WHERE version = ?）绕过 InnoDB 锁机制
示例：下面这段容易引发死锁
START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1; -- 先锁 A UPDATE accounts SET balance = balance + 100 WHERE id = 2; -- 再锁 B COMMIT;
如果另一事务按 id=2→id=1 顺序更新，就构成环。改成固定顺序（比如总是小 ID 优先）就能从源头掐断。
监控和定位真正在哪卡住
别猜“是不是检测太慢”，先看是不是锁本身设计有问题：
- 查当前死锁日志：
SHOW ENGINE INNODB STATUS\G，重点看LATEST DETECTED DEADLOCK段，它会告诉你哪两个事务、哪些锁、什么语句撞上的 - 开慢日志 +
long_query_time = 0，结合log_output = TABLE，查mysql.slow_log里带Lock_wait的记录 - 用
performance_schema.data_locks和data_lock_waits实时看谁在等谁（需提前开启相关 consumers）
死锁日志里出现大量 WAITING FOR THIS LOCK TO BE GRANTED 但没报死锁？说明锁等待超时（innodb_lock_wait_timeout）先触发了，不是检测问题，而是锁争抢太激烈或事务太久。
真正难处理的，是那种锁等待链深、事务嵌套多、又混着存储过程和触发器的场景——这时候检测本身不是瓶颈，锁设计才是根因。
