不建议在生产环境关闭 innodb_deadlock_detect，它并非性能瓶颈根源而是问题暴露器；关闭后事务将阻塞至超时而非及时回滚，导致连接堆积、超时蔓延、诊断困难。
不建议在生产环境关闭 innodb_deadlock_detect，它不是性能瓶颈的根因，而是问题暴露器——关掉只会让事务卡死、连接堆积、超时蔓延，最终更难诊断。
为什么关掉 innodb_deadlock_detect 反而更危险
MySQL 8.0 默认开启该参数，本质是把原来被静默忽略的环形等待（即潜在死锁）全部检测并主动中止。错误日志里突然密集出现 Deadlock found when trying to get lock，大概率不是死锁变多了，而是“终于报出来了”。
关掉后，InnoDB 不再构建 wait-for graph 判断循环依赖，事务会一直阻塞，直到触发 innodb_lock_wait_timeout（默认 50 秒）才回滚。在超高并发写场景下，这极易导致：
-
Threads_running持续高位，连接池耗尽 - 大量事务卡在
updating或Waiting for table metadata lock状态 - 监控看不到死锁日志，但应用层表现为批量超时、重试风暴
真正有效的高并发写入优化路径
死锁感知频率上升，90% 以上源于应用层加锁顺序混乱或事务粒度失控，而非检测机制本身。优先做这些：
- 统一 SQL 中
WHERE id IN (...)的 ID 排序：应用层对参数列表先ORDER BY id ASC，避免 ORM（如 MyBatis<foreach>）无序拼接 - 热点行更新强制加锁顺序：例如账户扣减，改用
SELECT ... FOR UPDATE ORDER BY id ASC，哪怕只查一行 - 拆分大事务：单事务内避免跨多张表更新 + 复杂计算；把“查→算→更”拆成原子步骤，用应用层幂等控制
- 确认
innodb_flush_log_at_trx_commit = 2已生效，并同步调大innodb_log_file_size（目标 checkpoint 间隔 ≥60 秒），否则刷盘跟不上，innodb_row_lock_time会反升
如果真要临时关闭，必须配套防御措施
仅限压测或极短时间灰度验证，且必须同步落实：
- 设
innodb_lock_wait_timeout = 3（秒），防止事务无限期挂起 - 开启
innodb_print_all_deadlocks = ON，持续采集日志，用脚本扫描INFORMATION_SCHEMA.INNODB_TRX中trx_started超过 2 秒的长事务 - 监控
Threads_connected和Aborted_clients，突增说明有连接被异常中断 - 绝对不能单独调这个参数：必须搭配
sync_binlog = 0（主从一致性风险自担）和innodb_io_capacity按 SSD 实际 IOPS 设置
最常被忽略的一点：MySQL 8.0 的行锁唤醒策略更公平，过去靠“抢跑”侥幸成功的逻辑，在 8.0 下更容易暴露为阻塞链。这不是配置能绕过的，得回到业务 SQL 和事务边界去重构。
