auto_increment在分库分表下必然冲突，因其设计未考虑分布式场景；各分表独立自增导致id重复，步长隔离仅适用于静态集群且主从切换易出错；号段模式（如leaf）通过批量预取+内存缓存+cas更新实现高可用mysql兼容方案。
直接用 MySQL 的 AUTO_INCREMENT 在分库分表后必然冲突，这不是配置问题，而是设计层面的失效——它根本就不是为分布式场景设计的。
为什么 AUTO_INCREMENT 在分库分表下一定会出问题
每个物理分表都维护自己的自增计数器，INSERT INTO order_01 和 INSERT INTO order_02 各自从 1 开始递增，插入 10 条后两个表都可能生成 ID=10。哪怕你用 auto_increment_offset + auto_increment_increment 做步长隔离，也只适用于固定节点数、不扩容的静态集群，且主从切换时极易因同步延迟或回滚导致重复发号。
- 分片键和主键分离后，
ORDER BY id失去全局时序意义 - 跨分片
JOIN或UNION时 ID 冲突直接破坏业务逻辑（比如订单状态查不到） - MyCAT 的
sequnceHandlerType=1（数据库方式）本质还是单点写sequence表，成了新瓶颈
真正可用的 MySQL 原生兼容方案：号段模式（Segment）
核心是“批量预取 + 内存缓存”，把数据库 IO 从每次发号降为每千次一次。关键不在 SQL 多炫酷，而在事务控制和失败兜底。
- 建一张
sequence_pool表，字段含name、current_val、step、version（用于 CAS 更新） - 发号时执行：
UPDATE sequence_pool SET current_val = current_val + step, version = version + 1 WHERE name = 'order_id' AND version = ? - 应用拿到新
current_val后，在内存中逐个分配，用完再触发下一轮UPDATE - 必须加
SELECT ... FOR UPDATE或乐观锁重试，否则并发 UPDATE 可能覆盖彼此
美团 Leaf 的双 Buffer 就是这思路的增强版：Buffer A 用到 50% 时异步加载 Buffer B，彻底消除获取号段时的 RT 毛刺。
绕不开的坑：时钟回拨与 ID 重复风险
雪花算法（Snowflake）看似优雅，但一旦服务器时间回拨（NTP 校准、运维误操作），同一毫秒内生成的 ID 就可能重复。MySQL 环境里更麻烦——你没法在 SQL 层做毫秒级时钟校验。
- 纯数据库方案（如号段模式）完全规避时钟依赖，但需接受 ID 不严格单调（号段之间有跳跃）
- 如果业务强要求“趋势递增”，建议用
REPLACE INTO guid (stub) VALUES('a')+LAST_INSERT_ID()组合，MyISAM 引擎下性能尚可，但注意它不支持事务回滚 -
INCRin Redis 虽快，但若用 RDB 持久化，重启后会丢序列；AOF 重放又慢——必须搭配定时快照 + 偏移量补偿
最常被忽略的一点：ID 的“唯一性”永远是针对业务语义的。订单 ID 重复是灾难，但日志 trace_id 重复可能只是排查变难。别一上来就上 ZooKeeper 或混合架构，先看你的 SELECT COUNT(*) 是否真卡在 ID 生成这一步。
