MySQL自增主键断号是InnoDB为提升并发性能与事务隔离性所做的主动设计，并非bug；事务回滚、唯一键冲突、批量插入等均会预分配ID且不可回收，8.0+通过redo log持久化确保重启后继续递增。
自增主键断号的根本原因不是“出错”，而是设计使然
MySQL 的 AUTO_INCREMENT 从不承诺连续，断号是正常行为，不是 bug。它本质是一个「乐观分配器」：只要事务申请了 ID，就立刻递增计数器，哪怕后续回滚、冲突或失败，这个 ID 也不会回收。这是为了性能和并发安全做的取舍。
常见触发断号的场景包括：
- 事务中插入后执行
ROLLBACK—— ID 已分配，计数器已+1，但行没存住 - 插入时违反
UNIQUE或PRIMARY KEY约束（如重复uid），语句失败但 ID 已消耗 -
INSERT ... SELECT、REPLACE INTO、INSERT IGNORE等批量操作中部分行失败 - 使用
innodb_autoinc_lock_mode=2（MySQL 8.0 默认）时，并发插入会交错分配 ID，天然不连续
不同 innodb_autoinc_lock_mode 值对断号的影响
锁模式决定 ID 分配时机和范围，直接影响断号频率与可预测性：
-
innodb_autoinc_lock_mode=0（传统模式）：语句级表锁，保证严格连续，但并发极差，仅用于旧版 SBR 复制 -
innodb_autoinc_lock_mode=1（默认，连续模式）：简单 INSERT 用轻量互斥锁，批量 INSERT（含INSERT ... SELECT）用表锁——批量内连续，跨批量可能断号 -
innodb_autoinc_lock_mode=2（交错模式）：所有 INSERT 都只在分配 ID 时加瞬时互斥锁，ID 按线程请求顺序交错发放，断号最频繁，但并发最高，RBR/GTID 环境必备
可通过 SELECT @@innodb_autoinc_lock_mode; 查看当前值；修改需在配置文件中设置并重启 mysqld。
MySQL 5.7 和 8.0 在重启后 AUTO_INCREMENT 表现差异
断号是否“雪上加霜”，取决于版本如何恢复计数器：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- MySQL 5.7 及更早：计数器仅存于内存，实例重启后执行
SELECT MAX(id) + 1 FROM tbl重新初始化——若之前有大量回滚/失败，这个值可能远小于实际用过的最大 ID，导致“跳号”看似缓解，实则掩盖了历史断号 - MySQL 8.0+：计数器持久化到 redo log，重启后恢复为上次分配的值（即真正“记住”了断掉的 ID），所以重启后继续从更高位置开始，断号更显眼但更真实
这意味着：MySQL 8.0 的断号现象更“诚实”，也更容易被监控系统捕获（比如通过 SHOW CREATE TABLE 观察 AUTO_INCREMENT=xxx 值持续跳升）。
主从之间 AUTO_INCREMENT 不一致的典型路径
主从断号不一致往往不是复制本身出错，而是主库行为未被从库“复刻”：
- 主库上执行
INSERT ... ON DUPLICATE KEY UPDATE，因冲突未插入新行，但主库仍消耗了一个 ID；从库按 RBR 回放时，该语句不触发自增逻辑，ID 未消耗 → 主从AUTO_INCREMENT值从此错开 - 主库开启
innodb_autoinc_lock_mode=2，而从库误配为=1，会导致同一批并发插入在主从产生不同 ID 序列 - 手动
ALTER TABLE ... AUTO_INCREMENT = N只作用于当前实例，不会同步到从库，极易引发后续主键冲突
检查主从一致性最直接的方式是分别执行 SHOW CREATE TABLE tbl_name，比对输出中的 AUTO_INCREMENT= 后数值——这个值不参与复制，必须人工对齐或接受其差异。
断号本身不可消除，但可以被理解、预判和收敛。真正危险的不是 ID 不连续，而是把业务逻辑（比如分页、导出序号、对外展示编号）耦合在 AUTO_INCREMENT 上。它的唯一契约只有两个：NOT NULL 和 UNIQUE。
