分段id生成方案是解决mysql分库分表后自增id冲突最常用、落地最成熟的手段，通过错峰分配（步长+偏移量）实现多库id互不重叠，适用于同机房、分库稳定的中大型业务。
分段ID生成方案是解决MySQL分库分表后自增ID冲突最常用、落地最成熟的手段之一。它不依赖外部服务，复用数据库自身能力，兼顾有序性、唯一性和可运维性。
分段ID的核心原理
本质是“错峰分配”：多个库或表共享同一套ID序列规则，但通过步长（increment）和起始偏移量（offset）人为划分互不重叠的ID区间。
- 若共N个分库，统一设
auto_increment_increment = N - 第i个库（i从1开始）设
auto_increment_offset = i - 这样库1生成1, 1+N, 1+2N…；库2生成2, 2+N, 2+2N…，以此类推
典型配置示例（3库10表场景）
以电商订单系统为例，3个订单库（order_db_1/2/3），每个库内10张表（order_0~order_9）：
- order_db_1：全局步长=3，偏移量=1 → ID为1,4,7,10…
- order_db_2：全局步长=3，偏移量=2 → ID为2,5,8,11…
- order_db_3：全局步长=3，偏移量=3 → ID为3,6,9,12…
- 每张表无需单独设AUTO_INCREMENT起始值，由全局offset控制即可
必须注意的实操细节
看似简单，但几个关键点常被忽略：
-
offset必须在连接建立前设置：MySQL的
auto_increment_offset是会话级变量，需在每次连接初始化SQL中显式执行，或通过连接池配置自动注入 - 重启后offset不持久：MySQL 5.7及之前版本，该参数重启即失效；8.0+虽支持持久化，仍建议在应用层做兜底校验
- 步长变更需全量同步：扩容到4库时，所有库步长必须同时改为4，且offset重新映射为1/2/3/4，否则ID必然重叠
- 不适用于跨机房部署：不同地域MySQL实例无法共享全局offset，此时应转向Snowflake或号段模式
适合谁用？什么情况下慎用？
该方案最适合同机房、同MySQL集群、分库数量稳定的中大型业务。
- ✅ 推荐场景：日均百万级订单、3–8个分库、无频繁扩缩容计划
- ❌ 慎用场景：微服务多语言混合架构、需要秒级弹性伸缩、对ID长度敏感（如短链生成）
- ⚠️ 替代提示：若已用云数据库（如阿里云PolarDB、腾讯云TDSQL），优先启用其内置的分布式序列（如Sequence对象），比手动调参更可靠
