设innodb_autoinc_lock_mode=2仅对insert values()类简单插入无锁，对insert select等仍需语句级锁；必须同时满足binlog_format=row、enforce_gtid_consistency=on才生效，否则实际仍按mode=1运行。
直接设 innodb_autoinc_lock_mode=2 不等于并发就变高
很多线上服务在压测时发现 INSERT 延迟飙升，第一反应是“调高自增锁模式”，但盲目 SET GLOBAL innodb_autoinc_lock_mode=2 后没效果，甚至报错。根本原因是：MySQL 8.0 对 mode=2 加了硬性校验，缺一不可——binlog_format 必须为 ROW，且 enforce_gtid_consistency 必须为 ON。否则 MySQL 启动时拒绝加载，或运行中降级警告，实际仍按 mode=1 执行。
验证方式不是看配置文件写了什么，而是连上后执行：
SELECT @@binlog_format, @@enforce_gtid_consistency, @@innodb_autoinc_lock_mode;
三者必须同时返回 'ROW'、'ON'、2。如果 @@binlog_format 是 STATEMENT 或 MIXED，mode=2 不生效，INSERT SELECT 类语句照旧排队卡住。
INSERT INTO ... SELECT 卡住？innodb_autoinc_lock_mode=2 对它无效
mode=2 只对简单 INSERT（如 INSERT INTO t (a) VALUES (1),(2)）跳过 AUTO-INC 锁；对含子查询、批量来源的语句，InnoDB 仍会加表级 AUTO-INC 锁，且锁持有到语句结束。这是设计使然，不是配置漏了。
常见卡点场景包括：
INSERT INTO orders SELECT * FROM tmp_orders WHERE status = 'ready'REPLACE INTO log_events SELECT ... FROM raw_logs-
LOAD DATA INFILE导入大文件
解法不是换模式，而是拆语句：
- 把大范围
SELECT拆成带WHERE id BETWEEN ? AND ?的小批次，每次最多 500 行 - 避免在子查询里用
ORDER BY RAND()或多表 JOIN，这类操作会让优化器误判行数，触发更保守的锁策略 - 监控状态变量
Innodb_autoinc_readiness_wait，值持续 > 10ms 就说明自增就绪等待已成瓶颈
为什么开了 mode=2，INSERT ... ON DUPLICATE KEY UPDATE 还是慢？
这不是自增锁的问题，是唯一键冲突引发的行锁队列。该语句执行路径本质是“先查再插再更新”，哪怕 ID 分配无锁，它仍要对唯一键对应记录加 X 锁 + insert intention 锁。如果多个线程反复撞同一个低区分度字段（比如都用 status='processing'），就会在那条记录上形成锁等待链。
真正要改的是业务逻辑和索引设计：
- 别拿
status、type这类低基数字段建UNIQUE索引 - 高频 upsert 场景优先用
INSERT IGNORE，失败再重试，比 update 更轻量 - 实在要用
ON DUPLICATE KEY UPDATE，确保唯一键字段本身足够离散（如用户 ID、订单号）
重启后参数失效？my.cnf 写了也不生效的真相
SET GLOBAL innodb_autoinc_lock_mode = 2 只影响新建立的连接，已有连接继续沿用旧值。更重要的是：MySQL 重启后会读取配置文件，但如果你改的是 my.cnf 却没生效，大概率是以下原因：
- 配置写在了错误 section 下（必须放在
[mysqld]段内） - MySQL 启动时读的是另一个配置文件（用
mysqld --help --verbose | grep "Default options"确认路径） - 配置项被环境变量或启动命令行参数覆盖
最稳妥的做法：在 [mysqld] 下明确写全三项：
binlog_format = ROW<br>enforce_gtid_consistency = ON<br>innodb_autoinc_lock_mode = 2
然后重启 mysqld，再用 SELECT @@... 验证。别信“改了配置就完事”，生产环境必须看到三个值同时生效才算落地。
真正容易被忽略的是：mode=2 下 ID 分配不可预测，应用层若依赖“刚插入的 ID 紧邻前一个”做关联查询，或分库分表中间件靠 ID 单调递增做路由，切换前必须确认兼容性。空洞不是 bug，是设计代价。
