MySQL中auto_increment_increment与offset必须成对配置于my.cnf并重启生效，单独SET GLOBAL或SESSION设置无效；ALTER TABLE AUTO_INCREMENT值受模运算约束，非直接设定。
auto_increment_increment 和 auto_increment_offset 必须成对设且用 GLOBAL
单独改 auto_increment_increment 或只设 auto_increment_offset 没用，MySQL 会按默认 offset=1、increment=1 补全逻辑，导致 ID 仍重叠。必须同时设两个变量，且必须用 SET @@global.auto_increment_increment = N 和 SET @@global.auto_increment_offset = M。SESSION 级设置对连接池（如 HikariCP）完全无效——应用一拿连接就可能落到没设过变量的会话上。
配置必须写进 my.cnf 并重启 mysqld，不能靠 SET GLOBAL 临时生效
运行时执行 SET GLOBAL 看似成功，但 MySQL 8.0 不支持热重载，复制线程和新连接仍按配置文件初始化；5.7 更是重启后全丢。正确做法是：
- 编辑
/etc/my.cnf的[mysqld]段 - 添加
auto_increment_increment = 4和auto_increment_offset = 1（其他实例依次为 2/3/4） - 执行
systemctl restart mysqld，不是 reload - 连上后验证：
SHOW VARIABLES LIKE 'auto_increment%'，值必须是你写的数字，不是 1
ALTER TABLE ... AUTO_INCREMENT = X 不等于起始值，它受 offset+increment 约束
ALTER TABLE t AUTO_INCREMENT = 1001 只是“提示”下一条插入从多少开始，MySQL 实际会向上取整到第一个满足 (next_id - offset) % increment == 0 的数。比如 offset=2、increment=4，你设 AUTO_INCREMENT = 1001，实际下一条是 1002（因为 1001 % 4 = 1 ≠ 2），不是 1001。验证方式：插入一条空记录后查 SHOW CREATE TABLE t，看输出里 AUTO_INCREMENT=xxx 的值是否符合模运算规则。
分库分表时主键不冲突 ≠ 数据不冲突，路由错误照样炸
即使四个库的 offset 设得 perfectly，只要应用层没绑定连接到对应分片（比如 ShardingSphere 配置漏掉 auto-increment 相关参数），或者中间件把某条 INSERT 错发到非目标库，ERROR 1062 (23000): Duplicate entry 立刻报出来。更隐蔽的是：MySQL 5.7 重启后会扫描当前最大 ID 再加 increment，如果历史数据没对齐 offset，可能跳回一个已存在的值——这个细节几乎没人检查。
