根本原因是InnoDB在innodb_autoinc_lock_mode=1下对INSERT SELECT等语句加AUTO_INC表级锁，整条语句执行完才释放，导致其他INSERT排队；改用多值INSERT、LOAD DATA或调整写法可绕开。
为什么INSERT SELECT一跑，其他插入就全堵住？
根本不是行锁或间隙锁的问题，是 InnoDB 在分配自增值时升级了锁粒度。默认 innodb_autoinc_lock_mode = 1 下，只要语句里带 SELECT（比如 INSERT INTO t SELECT * FROM s）、REPLACE SELECT 或 LOAD DATA，InnoDB 就会在执行前加语句级 AUTO_INC 表锁，整条语句结束才释放——哪怕只有一条这样的语句在跑，所有后续 INSERT 都得排队等。
常见现象：
-
SHOW PROCESSLIST里一堆Waiting for table level lock - 慢日志里单条
INSERT耗时从几毫秒跳到几百毫秒甚至秒级 -
SHOW ENGINE INNODB STATUS显示waiting for auto-inc lock on xxx
innodb_autoinc_lock_mode=2 真的能解耦并发吗？
innodb_autoinc_lock_mode = 2 是“预分配段”策略：一次拿一段 ID（如 100 个），事务回滚后不回收，导致主键空洞。这不是 bug，是设计取舍。
但它有硬限制：
- 仅对
INSERT INTO t VALUES (),()这类纯值插入生效 -
INSERT INTO t (id, name) VALUES (NULL, 'a')属于 mixed-mode，不享受无锁 - 含
SELECT、ON DUPLICATE KEY UPDATE或REPLACE的语句，照样退化为语句级锁 - 必须确保
binlog_format = ROW，否则主从复制可能中断；用SELECT @@binlog_format验证
不改参数，怎么从写法上绕开自增锁瓶颈？
参数只是工具，真正压垮并发的常是写入模式本身。与其死磕锁，不如换写法：
- 用多值
INSERT INTO t (a,b) VALUES (),(),()替代循环单条，每批控制在 100–500 行，显式事务包裹（BEGIN; ... ; COMMIT） - 高冲突场景慎用
ON DUPLICATE KEY UPDATE：唯一键冲突频繁时易升间隙锁，考虑先SELECT ... FOR UPDATE再决定INSERT或UPDATE - 超大批量导入优先用
LOAD DATA INFILE：绕过 SQL 解析层，快 3–10 倍，但注意secure_file_priv路径限制和编码一致 - 批量插入前必须
ORDER BY id ASC（应用层排序），不能依赖数据库排序；乱序插入会触发交叉间隙锁等待
主键冲突频繁时，ON DUPLICATE KEY UPDATE 为什么比 INSERT IGNORE 更重？
INSERT IGNORE 在遇到唯一键冲突时直接跳过，不加 X 锁、不触发行更新、不维护二级索引变更日志；而 ON DUPLICATE KEY UPDATE 即使 UPDATE 子句没真改字段，也会对目标行加 X 锁，并可能引发索引分裂。
实际建议：
- 语义允许“冲突即丢弃”时，无条件选
INSERT IGNORE - 需要返回是否插入成功，用
ROW_COUNT()判断：返回 1 = 新增，0 = 冲突忽略 - 不要写
ON DUPLICATE KEY UPDATE id=id这种伪更新——它照样锁行，且让优化器无法走覆盖索引
真正的难点不在参数开关，而在写法与业务语义的对齐：ID 是否必须连续？冲突是否可丢弃？插入是否可拆批？这些判断一旦错位，调再高的 innodb_autoinc_lock_mode 也救不回来。
