alter table … auto_increment=100 仅在目标值大于当前最大自增值时生效，innodb重启后重新推导，myisam则持久化存储于.myi文件；它本质是缓存机制，非强一致性字段。
ALTER TABLE … AUTO_INCREMENT=100 为什么有时不生效
MySQL 中设置自增初始值最常用的是 ALTER TABLE t AUTO_INCREMENT = 100，但它是否真正写入、何时生效，取决于存储引擎和当前表状态。
关键点在于：该语句**只设置下一次 INSERT 的起始值，且仅当指定值大于当前最大自增值时才被接受**。如果表里已有 id=150 的记录，再执行 AUTO_INCREMENT=100 会被 MySQL 忽略（不会报错，但 SHOW CREATE TABLE 里也看不到变化）。
- 执行前先查当前最大值：
SELECT MAX(id) FROM t，确保目标值 > MAX(id) - InnoDB 表在重启后会重新扫描索引找最大值，所以
AUTO_INCREMENT值不是“永久写死”的，而是“下次插入前的临时起点” - MyISAM 则把该值存进 .MYI 文件，重启后仍保留（更接近“持久化”）
InnoDB 自增主键重启后重算的逻辑
InnoDB 不把 AUTO_INCREMENT 值持久化到系统表或数据字典中，而是在每次打开表时，通过聚簇索引（主键索引）扫描最后一页的记录来推断下一个值。这个行为从 MySQL 8.0 开始有优化，但默认仍不保证绝对连续或可预测。
- MySQL 5.7 及之前：每次重启后都执行
SELECT MAX(ai_col) + 1 FROM t（全表扫描，慢） - MySQL 8.0+：改用索引末尾页快速定位，但若该页被 purge 或未刷盘，仍可能漏掉刚插入未提交的记录
- 事务回滚不影响已分配的自增值——即使 INSERT 回滚了，后续插入仍会跳过那个 ID
- 批量插入（如
INSERT INTO t VALUES (),(),()）会预分配一段值，可能导致“空洞”
MyISAM 的 AUTO_INCREMENT 是真持久化的吗
是的，MyISAM 把当前自增值直接存在表的索引文件（.MYI）头部，重启后读取即用，不需要扫描数据。但这带来两个实际限制：
- 并发插入时，MyISAM 用表级锁保护自增值更新，高并发下容易成为瓶颈
- 如果手动修改
.MYI文件（比如用 hex 编辑器），可能破坏结构导致表损坏 - 不支持
innodb_autoinc_lock_mode这类细粒度控制，也没有“交错分配”或“连续分配”模式可选
换句话说，MyISAM 的“持久化”更机械，但缺乏 InnoDB 那种事务安全与并发适应性。
想彻底固化自增起点？别依赖 ALTER TABLE
如果业务要求某张表的下一条记录必须是 ID=1000，且不能受重启、并发、回滚影响，靠 ALTER TABLE ... AUTO_INCREMENT 并不可靠。更稳妥的做法是：
- 清空表后立刻插入一条占位记录：
INSERT INTO t (id, ...) VALUES (999, ...); DELETE FROM t WHERE id = 999;，再设AUTO_INCREMENT=1000 - 使用
TRUNCATE TABLE（它会重置自增值，但会删所有数据，且 MyISAM 和 InnoDB 行为一致） - 对新建表，在建表时就写死：
CREATE TABLE t (id BIGINT PRIMARY KEY AUTO_INCREMENT) AUTO_INCREMENT = 1000; - 注意：MySQL 8.0.24+ 支持
SET PERSIST auto_increment_offset = 1000，但这影响的是全局服务器变量，不是单表，慎用
真正容易被忽略的是：自增值本质上是个“缓存+推导”机制，不是数据库的强一致性字段。它服务于性能与简单性，而不是精确序列控制。需要严格序号管理的场景，应该用单独的序列号服务或 UUID + 时间戳组合。
