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 当业务序号用——这些地方一松动，问题就藏不住了。
