MySQL 8.0+中AUTO_INCREMENT值已持久化，重启不重复；所谓“重复”多因显式插入ID或建表未设起始值导致碰撞，非机制缺陷。
AUTO_INCREMENT 重复问题在 MySQL 中极少真实发生——如果你看到“重复 ID”，大概率不是自增机制本身出错，而是你误判了“重复”的定义，或混淆了主键冲突与自增跳号。
MySQL 8.0+ 的 AUTO_INCREMENT 值已完全持久化（写入 redo log + 数据字典），崩溃重启后不会回退、不会复用已删除的 ID。所谓“重复”，99% 是以下两类情况之一：
- 插入时显式指定了 ID（如
INSERT INTO t(id, name) VALUES (100, 'x')），后续又由自增生成了同样的 100； - 表中已有数据，但建表时没设
AUTO_INCREMENT起始值，导致新插入时和旧数据 ID 碰撞。
真正需要干预的，是“自增计数器被意外抬高后无法回落”这类行为——它不违法，但可能影响分页、ID 长度预期或下游系统假设。
为什么 SHOW TABLE STATUS 显示的 Auto_increment 比 MAX(id) 大很多？
这是正常现象，尤其在批量插入、事务回滚、或使用 INSERT ... SELECT 后常见。InnoDB 的自增计数器一旦分配，就不会因回滚而回收。
-
INSERT INTO t(name) SELECT name FROM src LIMIT 1000：即使该语句最终只成功插入 1 条，InnoDB 也可能已预分配 1000 个 ID - 并发 INSERT 时，为避免锁争用，InnoDB 采用“批分配”策略（尤其在
innodb_autoinc_lock_mode = 1或2下） -
DELETE不影响计数器，TRUNCATE才会重置（但会重建表）
如何安全地重置 AUTO_INCREMENT 计数器？
不能靠 ALTER TABLE ... AUTO_INCREMENT = N 随意设小值——如果 N ≤ 当前表中最大 ID，MySQL 会自动向上修正到 MAX(id) + 1，且不报错、不提示。
- 确认当前最大 ID：
SELECT MAX(id) FROM t - 设为安全值（必须 > 当前最大 ID）：
ALTER TABLE t AUTO_INCREMENT = 10000 - 若真要“压缩”ID（比如清空后重排），只能用重建方式：
CREATE TABLE t_new AS SELECT ROW_NUMBER() OVER(ORDER BY id) AS id, ... FROM t; ALTER TABLE t_new ADD PRIMARY KEY(id); RENAME TABLE t TO t_old, t_new TO t; - 注意：重建操作会锁表、阻塞写入，生产环境慎用
innodb_autoinc_lock_mode 影响哪些行为？
这个参数控制自增 ID 分配时的并发策略，直接影响是否“跳号”以及是否可预测。
-
innodb_autoinc_lock_mode = 0（传统模式）：所有 INSERT 都加表级AUTO-INC Lock，ID 连续、可预测，但并发差 -
innodb_autoinc_lock_mode = 1（默认，交错模式）：简单 INSERT（如单行、多行常量）用轻量 mutex，批量 INSERT（如INSERT ... SELECT）仍用表锁，ID 可能跳号但性能好 -
innodb_autoinc_lock_mode = 2（无锁模式）：所有 INSERT 都只用 mutex，最高并发，但 ID 跳号最明显，且 binlog 可能不安全（需配合binlog_format=ROW）
线上环境不建议改 = 0，除非你明确要求 ID 绝对连续且能接受写入瓶颈。
insert ignore / on duplicate key update 不会触发自增 ID 分配吗？
会。只要语句含 INSERT 关键字，且目标表有 AUTO_INCREMENT 列，InnoDB 就会在解析阶段预分配一个 ID——哪怕最终因唯一冲突被忽略或转为更新。
- 执行
INSERT IGNORE INTO t(name) VALUES ('a'), ('b')，即使'a'已存在，'b'也会拿到下一个自增 ID，且'a'对应的 ID 已被消耗 - 同理，
REPLACE INTO先 DELETE 再 INSERT，会分配两个 ID（DELETE 不释放，INSERT 新分配） - 想规避 ID 浪费？用
INSERT ... SELECT ... WHERE NOT EXISTS替代，但要注意性能和一致性边界
真正难处理的，从来不是“怎么让 ID 不重复”，而是“怎么让业务逻辑不依赖 ID 的连续性或可预测性”。ID 是代理键，不是序号。一旦开始纠结跳号，往往说明模型或下游消费方已经越界了。
