直接改innodb_autoinc_lock_mode=2不能一劳永逸，它只对纯值插入跳过锁；含SELECT、ON DUPLICATE KEY UPDATE或显隐ID混用的语句仍触发语句级AUTO-INC锁。
直接改 innodb_autoinc_lock_mode=2 不能一劳永逸，它只对 INSERT INTO t VALUES () 类纯值插入跳过锁；只要语句里带 SELECT、ON DUPLICATE KEY UPDATE 或显隐 ID 混用，照样卡表级 AUTO-INC 锁。
确认是不是 AUTO-INC 锁真在阻塞你
别急着调参，先看现象是否匹配：
-
SHOW PROCESSLIST里大量线程状态是Waiting for table level lock - 慢日志中某条
INSERT耗时从几毫秒突增至几百毫秒甚至秒级，且语句含SELECT、REPLACE或LOAD DATA -
SHOW ENGINE INNODB STATUS\G的TRANSACTIONS部分出现AUTO_INC字样等待 - CPU 火焰图里
innodb_autoinc_lock相关函数占比异常高
哪些写法会强制触发语句级 AUTO-INC 锁
这类语句无论 innodb_autoinc_lock_mode 设成多少，InnoDB 都会升级为语句级锁（执行完才释放），是并发瓶颈的主因：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
INSERT INTO t SELECT * FROM s—— 最常见，哪怕只跑一条，后续所有插入都排队 -
REPLACE INTO t SELECT ...或INSERT IGNORE INTO t SELECT ... -
LOAD DATA INFILE（包括LOAD DATA LOCAL INFILE） -
INSERT INTO t VALUES (100,'a'), (NULL,'b')—— mixed-mode，显式 + 隐式混用，触发内部重试 -
INSERT ... ON DUPLICATE KEY UPDATE—— 即使没真正插入新行，也会推进自增计数器并加锁
不改参数也能绕开锁瓶颈的实操路径
真正压垮并发的常是写入模式本身。优先从 SQL 写法和应用层入手：
- 把大
INSERT INTO t SELECT ...拆成应用层分页：每次SELECT ... LIMIT 500，再拼成INSERT INTO t VALUES (),(),()...批量插入，显式事务包裹 - 高频冲突场景慎用
ON DUPLICATE KEY UPDATE；可改用先SELECT ... FOR UPDATE判断存在性，再决定INSERT或UPDATE - 大批量导入优先用
LOAD DATA INFILE（比 SQL 快 3–10 倍），但注意secure_file_priv路径限制和字符集一致 - 避免在
mode=2下混用显式 ID 和NULL；若必须指定部分 ID，统一用INSERT INTO t (id, name) VALUES (100,'a'), (101,'b')全显式 - 临时关闭约束提速：
SET UNIQUE_CHECKS=0+SET FOREIGN_KEY_CHECKS=0，导入完再恢复并ANALYZE TABLE
改参数前必须验的三件事
innodb_autoinc_lock_mode=2 不是免死金牌，漏掉任一检查都可能引发主从不一致或复制中断：
- 执行
SELECT @@binlog_format，结果必须是ROW；STATEMENT格式下mode=2会导致从库数据错乱 - 确认业务不依赖 ID 连续性：比如不用
id+1推下一条、不做基于 ID 的分页推算（WHERE id > ? LIMIT N是安全的，但WHERE id BETWEEN ? AND ?可能漏数据） - 检查是否有 ORM 自动生成了带条件的插入（如
INSERT IGNORE后又手动UPDATE），这类逻辑会放大空洞，且无法靠参数修复
最隐蔽的坑是：你以为在优化锁，其实问题出在写法本身——比如一条 INSERT SELECT 卡住 3 秒，后面 200 个并发插入全在等它释放 AUTO-INC 锁，而这个锁根本不是行锁，也不是间隙锁，就是一条语句级轻量表锁，却足以让整个表写入雪崩。
