MySQL无法关闭死锁检测，因其是InnoDB保障事务隔离正确性的强制机制；应通过减少等待图规模、统一加锁顺序、热点分片、批量操作等手段降低检测频率与开销。
死锁检测本身无法关闭，MySQL 没有 innodb_deadlock_detect 之类的开关
很多人搜索“关闭死锁检测”是想降低高并发更新热点行时的性能抖动，但 MySQL 的死锁检测是 InnoDB 事务引擎内建的强制机制，**不可禁用**。它在每次加锁失败时自动触发，遍历等待图（wait-for graph）判断是否存在环。这不是一个可配置的“功能”，而是事务隔离正确性的底层保障。
试图绕过它（比如用 SET innodb_lock_wait_timeout=1 强制快速超时）并不能消除检测开销，反而会让应用层收到更多 Lock wait timeout exceeded 错误，掩盖真实死锁问题。
真正有效的缓解手段：减少等待图规模和检测频率
死锁检测的耗时与等待图中涉及的事务数、锁数量呈近似平方关系。高并发下多个事务争抢同一行（如计数器、库存扣减），极易生成密集等待图。关键不是“关检测”，而是“不让它频繁触发”：
- 用
SELECT ... FOR UPDATE替代先SELECT再UPDATE，避免两次加锁，缩短事务持有锁的时间 - 确保所有业务逻辑按相同顺序访问多张表或同一表的多行（例如始终按
user_id升序更新），从源头破坏循环等待条件 - 对热点行做分片，比如把全局计数器拆成
shard_0到shard_31，用MOD(id, 32)路由，把单点争抢变成 32 个低竞争队列 - 将高频小更新合并为批量操作（如用
INSERT ... ON DUPLICATE KEY UPDATE代替多次单行UPDATE），降低事务总数
innodb_deadlock_detect=ON 是唯一合法值，但可以调优相关参数
虽然不能关检测，但能控制它的副作用：
-
innodb_lock_wait_timeout默认 50 秒，高并发场景建议设为 5–10 秒——不是为了“更快失败”，而是防止一个长等待事务拖垮整个等待图的检测效率 -
innodb_rollback_on_timeout应保持OFF（默认），否则超时后自动回滚会释放锁但不通知客户端，导致应用误判成功 - 监控
SHOW ENGINE INNODB STATUS输出中的deadlocks计数器，配合慢日志定位高频冲突的 SQL 模式（如都走WHERE status=1 ORDER BY created_at LIMIT 1）
替代方案：用应用层重试 + 更宽松的隔离级别
如果业务允许短暂不一致（如点赞数、浏览量），可考虑：
- 将事务隔离级别降为
READ COMMITTED，减少间隙锁范围，降低死锁概率 - 捕获
Deadlock found when trying to get lock错误，在应用层做指数退避重试（最多 3 次），比数据库反复检测更可控 - 对纯递增场景，改用
INSERT INTO t (counter) VALUES (1) ON DUPLICATE KEY UPDATE counter = counter + 1，利用唯一索引+原子更新避开行锁竞争
死锁检测的开销藏在并发密度里，而不是开关里。最常被忽略的是：没有分析具体哪几行、哪几个索引在反复成环，就直接调参或换方案。
