auto_increment不是黑盒，其行为受数据类型、锁模式、插入方式和事务共同影响；显式插入大id会更新计数器，删除不重置，仅truncate或alter table（值大于当前最大id）可改变起始值。
直接说结论：AUTO_INCREMENT 不是“设了就完事”的黑盒，它受数据类型、锁模式、插入方式和事务行为共同影响；多数线上问题都源于忽略 innodb_autoinc_lock_mode 或误以为删除数据会重置计数器。
为什么 INSERT INTO t (id, name) VALUES (100, 'x') 后下一条自增变成 101？
MySQL 的 AUTO_INCREMENT 计数器不是“记住上一个值”，而是每次显式插入一个大于当前最大值的 id 时，会把计数器更新为该值 + 1。这是故意设计的行为，不是 bug。
- 执行
INSERT INTO users (id, name) VALUES (100, 'alice')→ 成功，id=100被写入 - 再执行
INSERT INTO users (name) VALUES ('bob')→ 自动分配id=101（不是 2） - 即使中间删掉了 id=1~99 的所有行，计数器仍维持在 101
- 只有
TRUNCATE TABLE users会重置计数器（DDL 操作，隐式提交）
ALTER TABLE t AUTO_INCREMENT = N 什么时候生效？
这条语句只设置“下一个将被分配的值”，但前提是 N 必须大于当前表中该列的最大值，否则会被 MySQL 忽略（不报错，也不生效）。
- 如果表里已有
id=5, 8, 12，执行ALTER TABLE t AUTO_INCREMENT = 10→ 无效，下次插入仍是 13 - 必须写成
ALTER TABLE t AUTO_INCREMENT = 13或更大值才起作用 - 该操作不加表锁（InnoDB），但会触发元数据刷新，高并发写入时建议避开峰值
-
SHOW TABLE STATUS LIKE 't'中的Auto_increment字段显示的就是这个待分配值
批量插入（INSERT SELECT / LOAD DATA）为什么卡住或主键冲突？
这和 innodb_autoinc_lock_mode 设置强相关。默认值 1（连续锁模式）在批量插入时会对整张表加 AUTO_INC 表级锁，阻塞其他 INSERT；而 2（交错模式）虽并发高，但可能造成主键不连续、复制延迟或 binlog 顺序问题。
- 查当前模式：
SELECT @@innodb_autoinc_lock_mode -
0：传统锁模式（已弃用），全表锁，最安全但性能差 -
1：默认，简单 INSERT 不锁表，但INSERT ... SELECT会锁整个 AUTO_INCREMENT 区间 -
2：推荐用于高并发写入，但要求 binlog_format=ROW，否则主从不一致风险高 - 不要在生产环境随意改这个变量——它必须在 server 启动时设置，运行时修改无效
INT vs BIGINT 做 AUTO_INCREMENT 主键有什么实际区别？
不只是“能存多大”，更关键的是溢出后的行为和迁移成本。
-
INT UNSIGNED最大值是 4294967295，按每天 10 万条，约 117 年耗尽；但一旦接近上限，INSERT会直接报错ERROR 1467 (HY000): Failed to read auto-increment value from storage engine -
BIGINT UNSIGNED上限是 18446744073709551615，基本可视为“不会溢出”，适合订单号、日志表等高频写场景 - 从
INT改成BIGINT是 DDL 操作，会锁表（除非用 pt-online-schema-change 等工具） - 外键关联的字段也必须同步改成
BIGINT，否则建表失败
真正容易被忽略的点是：AUTO_INCREMENT 的“唯一性”只由索引保证，不是由机制本身保证；如果你手动插入重复值又没建主键/唯一索引，MySQL 根本不会拦你——它只负责“递增”，不负责“不重复”。
