MySQL自增ID在高并发下不会重复，由InnoDB自增锁或轻量级机制保证原子性；但可能跳号，且SHOW CREATE TABLE中AUTO_INCREMENT值突增是因缓存预分配与重启后重算所致。
MySQL 自增 ID 在高并发插入时会不会重复
不会重复，INSERT 语句触发的 AUTO_INCREMENT 值分配由 InnoDB 的自增锁（或新版本的轻量级互斥机制）保证原子性。只要表引擎是 InnoDB，且没手动用 REPLACE、INSERT ... ON DUPLICATE KEY UPDATE 或 INSERT ... SELECT 等特殊写法干扰自增逻辑，就不存在两个事务拿到相同 ID 的情况。
但要注意：不重复 ≠ 连续。自增 ID 可能跳号，尤其在事务回滚、批量插入预分配、或主从切换后启用 auto_increment_offset/auto_increment_increment 时。
为什么 SHOW CREATE TABLE 看到 AUTO_INCREMENT 值突然变大
这是 InnoDB 的“自增计数器缓存”行为：为了减少锁竞争，InnoDB 会一次预分配一段 ID（如 1–100），并把当前最大值记入内存。如果 mysqld 重启，它会扫描表中最大 ID 并加一作为新的起点——这个值可能远大于上次记录的 AUTO_INCREMENT 值，因为中间有未提交/已回滚的事务占用了编号。
-
innodb_autoinc_lock_mode = 1（默认）：普通 INSERT 不锁表，但INSERT ... SELECT会加表级自增锁 -
innodb_autoinc_lock_mode = 2：全部语句都走轻量级分配，但复制环境下要求binlog_format = ROW，否则主从不一致 - 显式指定
INSERT INTO t(id, name) VALUES (1000, 'x')后，下次自增仍从 1001 开始，但若该值已存在则报Duplicate entry '1000' for key 'PRIMARY'
多线程写入时，ID 分配延迟导致业务逻辑错乱怎么办
典型场景：用户注册成功后立即用刚生成的 id 查询记录，却查不到——不是 ID 冲突，而是事务还没提交，或主库写完、从库还没同步（尤其用了读写分离）。这时不能依赖自增 ID 的“即时可见性”。
解决思路：
- 写后立刻读，必须走主库，且确保事务已
COMMIT - 避免在应用层做“插入 → 查 ID → 更新状态”这种跨事务依赖，改用单条
INSERT ... RETURNING（MySQL 8.0.19+ 支持）或触发器生成关联字段 - 如果需要全局有序 ID（比如订单号），别直接用
AUTO_INCREMENT，改用REPLACE INTO+ 时间戳 + 随机段，或引入独立发号服务
主从架构下 AUTO_INCREMENT 主键真的安全吗
单主结构下安全；但如果启用了双主或多源复制，又没配置好 auto_increment_offset 和 auto_increment_increment，就会出现主键冲突。
例如两台主库都设 auto_increment_increment = 2，一台设 offset = 1，另一台设 offset = 2，这样各自生成的 ID 分别是 1,3,5… 和 2,4,6…，才不会撞。漏配任意一个参数，就可能在某次同步时触发：Duplicate entry '12345' for key 'PRIMARY'。
更隐蔽的问题是：某些运维操作（如用 mysqldump --single-transaction 导出再导入）会重置从库的 AUTO_INCREMENT 值，导致后续插入和主库冲突。
SET GLOBAL auto_increment_offset = 1; SET GLOBAL auto_increment_increment = 2;
这两个变量必须在所有主节点上持久化配置（写入 my.cnf），且重启后生效，仅 SET SESSION 无效。
真正难处理的不是并发分配，而是人为绕过自增机制、跨实例 ID 规划缺失、或把自增 ID 当业务序号用——这些地方一松动，问题就藏不住了。
