MySQL 8.0 并未取消自增主键锁，而是将默认 innodb_autoinc_lock_mode 从1改为2，即启用交错模式：所有INSERT均不持表级AUTO_INC锁，改用预分配ID段+轻量同步机制，在保证高并发性能的同时牺牲ID连续性与STATEMENT复制安全性。
innodb_autoinc_lock_mode=2 并不是“关闭自增锁”，而是换一种分配方式
直接设 innodb_autoinc_lock_mode = 2 不等于关掉锁，而是把语句级表锁换成无锁的原子计数器预分配。它只对 INSERT INTO t VALUES () 这类简单插入跳过锁；一旦语句里带 SELECT、REPLACE 或显式指定部分 ID（Mixed-mode），InnoDB 仍会退化为语句级 AUTO-INC 锁——所以你开了 mode=2 却还卡，大概率是 SQL 写法本身就不走轻量路径。
常见错误现象：
-
SHOW PROCESSLIST里大量出现Waiting for table level lock或waiting for auto-inc lock on t - 单条
INSERT INTO t SELECT ...执行几秒，期间所有其他插入都阻塞 -
information_schema.INNODB_METRICS中autoinc_wait_count持续上涨
必须同时满足两个硬性前提，否则 mode=2 无效或危险
mode=2 不是独立开关，它和 binlog 格式强绑定：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
binlog_format必须为ROW：执行SELECT @@binlog_format确认返回值是ROW；如果不是，MySQL 启动时可能报错或降级，主从复制会丢数据或中断 - 不能用于 MyISAM 表：该模式仅对 InnoDB 生效，且 MySQL 8.0 已移除 MyISAM 引擎支持
- 不兼容依赖 ID 连续性的逻辑：比如用
id + 1推算下一条、分页靠 ID 范围、分库分表中间件按 ID 单调性路由——这些都会出问题
验证是否真正生效，不能只看配置值
改完 innodb_autoinc_lock_mode 和 binlog_format 后，必须检查运行时行为：
- 执行
SHOW VARIABLES LIKE 'innodb_autoinc_lock_mode'和SHOW VARIABLES LIKE 'binlog_format'，双确认都是预期值 - 压测并发插入时，用
SHOW ENGINE INNODB STATUS查输出，确认没有线程在auto-inc相关状态上等待 - 观察
information_schema.INNODB_METRICS表中autoinc_wait_count是否稳定在 0 附近 -
SHOW TABLE STATUS显示的Auto_increment值跳变（如从 1001 直接到 1057）属于正常现象，不代表配置失败
真正容易被忽略的副作用：ID 分配不可预测
mode=2 下，ID 是预分配段（如一次拿 100 个），事务回滚后已分配 ID 不回收，导致空洞。这不是 bug，是设计取舍。但如果你的应用层做了“插入后立刻用刚生成的 ID 做关联查询”并假设它紧邻前一个 ID，这种逻辑会失效。另外，某些分库分表中间件依赖 ID 的单调递增性做路由，切换前务必确认兼容性——这点比性能提升更关键，也更容易在线上出问题。
