在分布式数据库中，主键自增（如传统单机数据库的 AUTO_INCREMENT）无法保证连续，核心原因是分布式架构的“多节点独立性”与“数据一致性需求”之间的矛盾——单机场景下由单一节点统一生成自增ID的逻辑，在多节点并行写入时会完全失效，必须通过特殊机制规避冲突，而这些机制恰恰导致了ID不连续。

要理解这一点，需要先对比“单机自增”与“分布式自增”的本质差异：

• 单机数据库：自增主键由数据库实例直接维护一个“全局计数器”，每次写入时计数器+1，天然连续（除非手动删除数据）；
• 分布式数据库：数据被分片存储在多个节点（如按用户ID哈希分片、按地域分片），若每个节点独立维护计数器，会直接导致ID冲突（比如节点A和节点B同时生成“1001”）；若让所有节点共享一个计数器，又会引发性能瓶颈（所有写入都需等待计数器锁释放，失去分布式并行优势）。

为解决“冲突”与“性能”的平衡问题，分布式数据库通常采用以下3类主键生成方案，而这些方案均会导致ID不连续：

一、预分配ID段（最常用方案）：节点“提前占号”导致间隙

这是MySQL分库分表（如ShardingSphere）、TiDB等分布式数据库最主流的方案，核心逻辑是给每个节点预分配一段不重叠的ID范围，节点在范围内自主生成自增ID，避免跨节点通信。

具体流程：

1. 全局ID管理器：维护一个“全局计数器”（可存在独立的元数据节点或分布式锁中）；
2. 节点预申请：当节点A的本地ID段（如1-1000）即将用完时，向全局管理器申请下一段（如1001-2000），并标记这段ID归自己所有；
3. 本地自增：节点A在1-1000范围内，按顺序给新数据分配ID（1、2、3…），无需与其他节点通信。

导致不连续的核心原因：

• 节点未用完ID段就下线：若节点A刚申请到1001-2000，仅用了1001、1002就因故障下线，剩余的1003-2000会永久闲置，后续其他节点的ID从2001开始，导致1003-2000成为“间隙”；
• ID段申请顺序与数据写入顺序不一致：节点B先申请2001-3000，节点A后申请1001-2000，若节点B先写入数据（生成2001），节点A后写入（生成1001），最终ID序列会出现“2001→1001”的跳跃，看似不连续。

二、UUID/GUID：完全随机的“无规律ID”

UUID（通用唯一识别码）是128位的随机字符串（如 550e8400-e29b-41d4-a716-446655440000），通过“时间戳+MAC地址+随机数”保证全球唯一，无需任何中心化管理。

为什么不连续：

• UUID的设计目标是“唯一性”而非“有序性”，生成的ID是完全随机的字符串（或数值化后的大整数），不存在“连续递增”的逻辑；
• 即使将UUID转为数值（如128位整数），其数值也会大幅跳跃（如前一个是10^{30，下一个可能是5×10}32），完全无连续性可言。

补充：UUID的变种（如Snowflake雪花算法）

雪花算法是“有序UUID”的改进方案，生成64位ID（结构：时间戳41位+机器ID10位+序列号12位），能保证“同一节点、同一毫秒内”的ID连续，但仍无法保证全局连续：

• 若不同节点的系统时间有偏差（如节点A比节点B快10ms），节点B在“慢时间”生成的ID会比节点A的小，导致全局序列跳跃；
• 若节点重启后序列号重置为0，可能出现“重启前生成1000，重启后生成0”的情况（虽可通过持久化序列号缓解，但无法完全避免）。

三、中心化ID生成器：“锁竞争”与“故障补偿”导致间隙

部分分布式数据库会采用“中心化ID生成器”（如独立部署的MySQL实例、Redis自增命令），所有节点写入前都向生成器申请ID，本质是“用单机自增逻辑模拟分布式场景”。

导致不连续的原因：

• 锁竞争导致的“预占”：为减少请求次数，生成器通常会“批量返回ID”（如一次给节点返回100个ID：1-100），若节点未用完就停止请求，剩余ID会成为间隙；
• 故障重试导致的ID浪费：若节点申请到ID=101后，因网络故障未成功写入数据，再次重试时会重新申请到ID=102，此时101就被浪费，导致间隙；
• 生成器自身的容错设计：部分生成器会“跳过一段ID”以避免故障恢复后的冲突（如故障前最后一个ID是500，恢复后直接从600开始），主动制造间隙。

总结：分布式ID“连续”与“可用”的取舍

分布式数据库的核心诉求是高可用、高并发、无冲突，而“ID连续”是单机场景下的次要需求，两者存在天然矛盾：

• 要保证连续，必须让所有节点共享一个“强一致计数器”，但会导致性能瓶颈（所有写入排队）和单点故障风险；
• 要保证高可用和高并发，必须采用“预分配”“随机生成”等机制，而这些机制必然导致ID不连续。

因此，在分布式场景中，“非连续自增ID”是技术权衡后的必然结果，实际业务中通常通过“业务字段补全排序”（如用创建时间 create_time 排序）替代“ID连续排序”，而非强求ID本身连续。