主从复制中auto_INCREMENT冲突的典型现象是Duplicate entry ‘X’ for key ‘PRIMARY’错误，根源在于误写从库或主从切换后未重置自增值；需配置auto_increment_increment和auto_increment_offset参数实现主从ID错开，切换后须手动校准AUTO_INCREMENT值，必要时可用UUID或雪花ID替代。
主从复制中 AUTO_INCREMENT 冲突的典型现象
主从复制下写入从库（比如误操作或双写），或者主库故障切从为主后未重置 AUTO_INCREMENT 值，会导致新插入记录的主键重复。常见错误是 Duplicate entry 'X' for key 'PRIMARY'，尤其在应用未做唯一性兜底时直接报错中断。
必须设置的两个关键参数
mysql 通过 auto_increment_increment 和 auto_increment_offset 控制自增步长与起始偏移，这是避免主从冲突最直接有效的手段。两者需成对配置，且在主从节点上取值不同：
- 主库设为：
auto_increment_increment = 2，auto_increment_offset = 1 - 从库（或另一主）设为：
auto_increment_increment = 2，auto_increment_offset = 2
这样主库生成 1、3、5…，从库生成 2、4、6…，互不重叠。注意：若部署多主（如双写架构），increment 应设为总节点数，offset 每节点唯一（1 到 N）。
切换主从后务必重置 AUTO_INCREMENT 值
从库提升为主库后，原主库可能已写入部分自增值，而新主库的 AUTO_INCREMENT 值仍沿用旧从库状态，极易与后续写入冲突。操作前必须手动校准：
- 查当前最大主键：
select MAX(id) FROM tbl_name; - 设新自增值（需大于该最大值）：
ALTER table tbl_name AUTO_INCREMENT = N; - 确认生效：
SHOW CREATE TABLE tbl_name;查看AUTO_INCREMENT字段值
这个步骤不能跳过，也不能依赖 mysqldump --auto-increment-offset 等导出参数替代——它们只影响导入时的初始值，不改变表元数据中的当前计数器。
使用 UUID 或雪花 ID 替代 AUTO_INCREMENT 的适用场景
当业务允许且写入压力大、分片多、主从角色频繁切换时，放弃 AUTO_INCREMENT 反而是更稳妥的选择。但要注意：
-
UUID()函数生成的是字符串，索引效率低，且无序写入易导致页分裂 - 若用程序侧生成雪花 ID（如 twitter Snowflake），需确保各节点时钟同步，否则可能重复或时间回拨出错
- MySQL 8.0+ 支持
UUID_TO_BIN(UUID(), 1)优化存储和排序，但迁移成本高
真正棘手的不是怎么选 ID 类型，而是现有系统里那些没加 ON UPDATE CURRENT_TIMESTAMP、没设 sql_mode=STRICT_TRANS_TABLES、也没做主键冲突重试的应用逻辑——它们会在 AUTO_INCREMENT 失控时悄无声息地丢数据。