mysql 8.0新特性如何优化死锁搜索算法_减少高并发下的锁检测开销-mysql教程-PHP中文网

mysql 8.0死锁检测机制未变，仍基于wait-for graph；真正降低开销靠避免触发检测，如用skip locked跳过已锁行、设innodb_autoinc_lock_mode=2减少auto_inc锁争用，而非关闭deadlock_detect。

mysql 8.0新特性如何优化死锁搜索算法_减少高并发下的锁检测开销

MySQL 8.0 的死锁检测机制本身没变，但可绕过它

MySQL 8.0 并未重写死锁检测算法（仍是基于 wait-for graph 的深度优先遍历），INFORMATION_SCHEMA.INNODB_TRX 和 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 查看锁状态的开销也没显著降低。真正能“减少锁检测开销”的，是避免触发检测——也就是让事务不进入死锁检测路径。

死锁检测只在事务尝试获取行锁失败、且等待队列中存在其他等待者时才启动；如果事务能立即获得锁，或明确知道不会冲突，检测根本不会发生
innodb_deadlock_detect 默认为 ON，但它不是性能开关，而是功能开关：关掉后，死锁不会被自动发现，而是靠超时（innodb_lock_wait_timeout）回滚，这会掩盖问题而非优化
高频更新热点行（如计数器、余额）是死锁检测开销飙升的主因，因为大量线程在同几个记录上循环等待

用 `SELECT ... FOR UPDATE SKIP LOCKED` 规避争抢

这是 MySQL 8.0 引入的最实用的死锁减负手段，适用于任务队列、分页取数、库存预占等场景。它不消除锁，但让并发线程跳过已被加锁的行，从而彻底避开等待和后续的死锁检测。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

传统 SELECT ... FOR UPDATE LIMIT 1 在高并发下极易形成“所有线程都卡在第一行”，触发密集的死锁检测
SKIP LOCKED 让每个线程拿到一个**未被锁定的可用行**，事务之间无交集，自然无等待、无图遍历、无检测开销
注意：它只对 READ COMMITTED 或 REPEATABLE READ 有效，且不能用于 UPDATE ... WHERE 的子查询中（会报错 ER_NOT_SUPPORTED_YET）
示例：
```
SELECT id, status FROM tasks WHERE status = 'pending' ORDER BY id LIMIT 1 FOR UPDATE SKIP LOCKED;
```
比 SELECT ... FOR UPDATE + 应用层重试快一个数量级，且不增加死锁检测压力

用 `innodb_autoinc_lock_mode = 2` 消除 AUTO_INCREMENT 锁瓶颈

大批量插入（如 INSERT ... SELECT、批量导入）在 innodb_autoinc_lock_mode = 1（默认）下会持表级 AUTO-INC 锁，阻塞其他插入并拉长锁等待链，间接放大死锁检测负担。

设为 2（interleaved 模式）后，InnoDB 仅对简单 INSERT 预分配连续 ID，其余语句（包括批量插入）不再阻塞，锁粒度从“表级瞬时”降为“行级无等待”
前提：必须使用 READ-COMMITTED 隔离级别，否则可能破坏语句级复制一致性（MySQL 5.7+ 已支持该组合）
验证是否生效：SHOW VARIABLES LIKE 'innodb_autoinc_lock_mode'; 返回 2，且慢日志中 AUTO_INC 相关等待消失
副作用：主从复制若用 STATEMENT 格式，需切为 ROW 格式，否则从库可能因 ID 不一致报错