数据库分表之后id主键的处理办法详解

前言

MySQL 分库分表(水平拆分)后，全局唯一且趋势递增的主键ID的设计是一个核心挑战。不能再使用单个数据库表的自增ID(AUTO INCREMENT)，因为它只能在单个数据库的单个表内保证唯一和递增。分库分表环境下需要全局唯一 ID。

数据库分表后，主键ID的处理是分布式系统的核心挑战之一。

分表后ID核心要求

主流ID生成方案详解

UUID

-- 生成示例：550e8400-e29b-41d4-a716-446655440000
SELECT UUID();

• 原理：基于时间、网卡 MAC 地址、随机数等生成一个(通常表示为32位16进制数)的全局唯一标识符。
• 优点：实现简单(几乎所有语言都有内置库)本地生成，无网络开销，性能极高。全球唯一性保证非常好。
• 缺点：
  • 完全随机无序：无序性导致索引碎片（B+树分裂），插入数据库时会导致严重的页分裂和索引碎片，极大影响写入性能(特别是 InnoDB 的聚集索引特性)。这是其最大缺点，通常不推荐用作数据库主键。
  • 存储空间大：长度过长(128 位/32 字符)，作为主键存储空间大，索引效率低。
  • 可读性差
• 适用：小型临时系统，对存储和性能要求不高，且需要强唯一性的非核心业务；或用作关联其他系统的唯一标识(如 Session ID，文件 ID)

数据库自增ID

集中分配：

• 原理：单独建立一个数据库(或一个数据库中的一张表)，专门用于生成 ID。该表使用 AUTO INCREMENT 功能。
• 优点：简单容易实现， 每次业务系统需要ID 时，向该表插入一条空记录，获取返回的自增 ID。
• 缺点：性能差，不推荐。

号段模式(Segment)：常用且推荐的方式

• 原理：业务系统启动时或 ID 用完时，向中心数据库批量申请一个号段(例如:1000~2000)。中心数据库更新最大值(当前最大值 + 步长，如 1000+1000=2000)，并返回号段范围(1000~2000)。业务系统在本地内存中使用这个号段(1000,1001,1002… 2000)分配完后再去申请新号段。
• 优点：
  • 生成的 ID 是数字，长度可控。
  • 趋势递增(号段内连续，号段间递增)
  • 性能较高(批量获取，减少数据库交互)
  • 易于扩展(可部署多个中心数据库实例，通过设置不同初始值和相同步长来避免冲突，如:DB1初始1步长 1000， DB2 初始 2 步长 1000)。
• 缺点：
  • 重启服务器可能会导致内存号段丢失
  • 中心数据库是潜在的单点故障(需要高可用部署：主从、集群)
  • 仍然依赖数据库，数据库性能可能成为瓶颈(虽然号段模式大大缓解)
  • 号段用完时，请求新号段会有轻微延迟

Redis原子自增

# Python示例
import redis
r = redis.Redis()
def next_id(shard_id):
    key = f"user_id:{shard_id}"
    return r.incr(key)  # 原子操作

• **原理：**利用Redis的INCR/INCRBY命令原子性来生成自增 ID。
• 实现方式：
  • 简单 INCR：INCR global id key。性能优于数据库简单获取，但仍需每次请求
  • 号段模式：类似数据库号段模式。使用INCRBY global_id_key step 一次性获取一个号段范围，然后在本地内存消费。
• 优点：
  • 性能极高（Redis 内存操作）
  • 生成的 ID 是数字，长度可控
  • 趋势递增
• 缺点：
  • 数据持久化问题：Redis宕机可能导致号段丢失(即使有 AOF/RDB恢复点可能不是最新状态)。需要仔细配置持久化策略，存在丢失一小部分 ID 的风险。这是最大缺点
  • 运维复杂度高
  • 需要解决 Redis 单点/集群问题(高可用部署)
• 适用：缓存层完备的高并发系统

Snowflake算法（主流方案）

// Java实现核心逻辑
long generateId() {
    long timestamp = System.currentTimeMillis() - START_TIME;
    return (timestamp << TIMESTAMP_SHIFT) |
           (dataCenterId << DATACENTER_SHIFT) |
           (machineId << MACHINE_SHIFT) |
           (sequence++ & MAX_SEQUENCE);
}

• **原理：**通过算法生成一个64位的Long型ID。

• 优点：

  • 高性能（单机每秒26万+）
  • 趋势递增
  • 无中心化依赖

• 缺点：

  • 时钟回拨问题： 这是最大挑战。如果服务器系统时间发生回退(如NTP 同步)，可能导致生成重复ID
  • 依赖机器配置：需要为每台部署 IDI生成服务的机器配置唯一的WorkerlD/DatacenterlD(可通过 Zookeeper、Consul、数据库等协调服务分配)
  • 强依赖机器时钟：时钟不准或跳跃会影响单调递增性

• 改进方案：

  • 关闭 NTP 同步(不推荐，时间会漂移)
  • 运行时检测到时钟回拨则等待或报错(影响可用性)
  • 扩展 WorkerlD 位数，预留一部分 ID 作为“时间回拨缓冲”(如美团 Leaf-Snowflake)

• 变种：

  • 百度 (UidGenerator) ： 基于 Snowflake ， 采用数据库分配 WorkerID，优化时钟处理

  • 美团 (Leaf):

    1. Leaf-Snowflake： 解决时钟回拨（使用 Zookeeper 顺序节点持久化时间戳）

    2. Leaf-Segment： 基于数据库号段模式的优化（双 Buffer 预加载）

  • 滴滴 (Tinyid)： 纯基于数据库号段模式的服务化组件。

选取规则

• 首选Snowflake其工业级变种(Leaf-Snowflake, UidGenerator)：性能最高、对数据库友好、无外部存储强依赖（除WorkerID配置）。需重点解决时钟回拨问题。适合追求高性能、低延迟的场景。
• 次选号段模式 (DB 或 Redis)：实现相对简单，性能较好。DB 号段更成熟可靠，Redis 号段需警惕持久化风险。适合中等规模、对时钟问题敏感或已有可靠 KV 存储的场景。Leaf-Segment/Tinyid是很好的服务化封装。
• ID生成服务：适合大型公司或复杂架构，需要统一管理 ID 生成，屏蔽底层细节。底层通常还是基于 Snowflake 或号段。
• UUID：仅适用于对存储和性能要求极低、且对顺序无要求的场景。
• DB 简单自增：绝对避免。

雪花算法 VS 号段服务

总结 

到此这篇关于数据库分表之后id主键的处理办法的文章就介绍到这了,更多相关数据库分表id主键处理内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论