mysql自增id不连续是正常设计，非故障；alter table auto_increment=n仅在n>max(id)时生效，否则静默设为max(id)+1；批量插入、事务回滚、唯一键冲突均会导致跳号，无法完全避免；业务需可控编号应弃用自增，改用雪花id等方案。
MySQL自增ID不连续不是故障，也不该“修复”——它本就是为唯一性而非连续性设计的。业务层依赖ID连续性，才是真问题。
为什么ALTER TABLE AUTO_INCREMENT = N经常没效果
这条语句只在 N > MAX(id) 时才真正生效，否则 MySQL 会静默忽略，实际设为 MAX(id) + 1。
- 执行前必须查：
SELECT MAX(id) FROM your_table WHERE id > 0; - 再对比
SHOW CREATE TABLE your_table;中当前AUTO_INCREMENT值，避免重复设置 - 在从库执行会导致 GTID 复制中断，主从自增值错位
- 设完不验证是常见失误，务必用
SHOW CREATE TABLE确认输出里值已更新
批量插入（INSERT INTO ... SELECT）为何跳号严重
这是 innodb_autoinc_lock_mode = 1（默认）下的正常行为：InnoDB 为提升并发性能，按 2 的幂次预分配 ID 段，比如插 5 行可能预占 1+2+4=7 个 ID。
- 查当前模式：
SELECT @@innodb_autoinc_lock_mode; - 设为 2（交错模式）可减少跳号，但要求
binlog_format = ROW，且不能完全消除 - 设为 0（传统锁表模式）能严格连续，但会显著拖慢大批量写入，线上禁用
- 真正可控的方式是改用单条
INSERT循环，或由应用层显式指定主键值
事务回滚和唯一键冲突也会消耗ID
只要 INSERT 语句中主键值为 NULL 或未指定，InnoDB 就会在语句解析阶段预分配 ID——无论后续是否 ROLLBACK、是否因 Duplicate entry 报错，该 ID 都不会回收。
- 例如已有
(1, 'a')，再执行INSERT INTO t VALUES (NULL, 'a');→ 报错但AUTO_INCREMENT已升至 2 - 这个行为与锁模式无关，无法通过任何 SQL 撤销已跳过的 ID
- 试图用
ALTER TABLE AUTO_INCREMENT = 1回拨，极易引发主键冲突，尤其在有历史数据的表上 - 若业务真需“可控编号”，应放弃
AUTO_INCREMENT，改用雪花 ID、数据库序列（如 PostgreSQL）或应用层生成
最常被忽略的一点是：MySQL 8.0 之前重启会丢失自增值，删光数据后重启可能导致 AUTO_INCREMENT 从高位跌回 1；而 8.0+ 通过 redo log 持久化，已解决此问题——升级比“修复连续性”更安全、更根本。
