分库分表分片建选择_分库分表中分片键的选择方式-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_42552857/article/details/146952935

在分库分表的场景下，直接使用数据库自身的主键生成机制（如自增ID）存在主键冲突的风险，尤其是在跨分片（分库分表）的场景中。以下是详细分析和解决方案：

问题核心：分库分表后主键冲突的原因

自增主键的局限性：
如果每个分片（分库或分表）独立使用数据库的自增主键（如 MySQL 的 AUTO_INCREMENT），则不同分片的自增ID会从 1 开始递增，导致不同分片的表中主键ID重复。例如：
- 分片1的表 t_order_0 的第一条记录ID为 1。
- 分片2的表 t_order_1 的第一条记录ID也为 1。
- 这两个记录的主键ID在全局范围内是重复的，无法保证唯一性。
跨分片查询的挑战：
如果业务需要跨分片查询（如全局唯一ID作为外键），自增ID的重复会导致数据关联失败或逻辑错误。

解决方案：如何避免主键冲突

根据知识库中的信息，以下是几种常见的解决方案及其优缺点：

1. 使用分布式唯一ID生成算法

推荐方案：通过算法生成全局唯一的ID，如 Snowflake、UUID、TinyID 等。

Snowflake（雪花算法）

原理：
生成一个64位的长整型ID，结构为 [时间戳(41位)] + [机器ID(10位)] + [序列号(12位)]，确保全局唯一且有序。
优点：
- 高性能（每秒生成百万级ID）。
- 有序性好，适合数据库索引。
缺点：
- 需要管理机器ID的唯一性（避免重复）。
- 时间戳需要同步，否则可能导致ID回拨。

示例配置（ShardingSphere）：

spring:
  shardingsphere:
    rules:
      sharding:
        key-generators:
          snowflake-id-gen:
            type: SNOWFLAKE
            props:
              worker.id=123 # 机器ID
        tables:
          t_order:
            key-generate-strategy:
              column: order_id
              key-generator-name: snowflake-id-gen

UUID

原理：
生成一个128位的唯一字符串（如 550e8400-e29b-41d4-a716-446655440000）。
优点：
- 简单易用，无需中心服务或协调。
- 全局唯一性有保障。
缺点：
- 长度长（36字节），占用存储空间。
- 无序性导致索引碎片化，影响查询性能。

示例配置（ShardingSphere）：

spring:
  shardingsphere:
    rules:
      sharding:
        key-generators:
          uuid-id-gen:
            type: UUID
        tables:
          t_order:
            key-generate-strategy:
              column: order_id
              key-generator-name: uuid-id-gen

2. 结合分片ID和自增ID

方案：在每个分片中使用自增ID，同时添加分片ID作为前缀，形成复合主键或唯一键。

实现方式

复合主键：
主键由 (分片ID, 自增ID) 组成，但需调整业务逻辑和查询方式。

单字段主键：
将分片ID和自增ID拼接成一个长整型或字符串，例如：

// 分片ID占8位，自增ID占56位
long compositeId = (shardId << 56) | autoIncrementId;

优点：

兼容自增ID的性能优势。
分片ID可辅助路由查询。

缺点：

需要自行管理分片ID的分配和冲突。
复合主键可能增加业务逻辑复杂度。

3. 使用数据库序列（Sequence）

方案：通过数据库的全局序列（如 Oracle Sequence 或 MySQL 的自增表）生成主键。

实现方式

全局序列：
在中心数据库维护一个自增序列表，每个分片请求序列值时获取唯一ID。
缺点：
- 高并发下可能成为性能瓶颈。
- 分布式环境下需保证序列的原子性和唯一性。

注意事项

避免手动赋值主键：
如果使用ShardingSphere等中间件的主键生成策略，需确保在代码中不主动设置主键值，否则会覆盖生成策略（如知识库[3]和[4]中提到的警告）。
索引与存储优化：
- 使用Snowflake生成的长整型ID（如 BIGINT）比UUID字符串更节省存储空间。
- UUID的无序性可能导致索引碎片化，需定期维护。
分片键的选择：
如果主键作为分片键（如按用户ID分片），需确保主键的均匀分布，否则可能导致数据倾斜。

总结

方案	唯一性	性能	有序性	存储开销	适用场景
Snowflake	高	高	高	低（8字节）	高并发、需要有序ID的场景
UUID	极高	中	低	高（36字节）	对唯一性要求极高，对性能要求低的场景
分片ID + 自增ID	高	高	高	中（需设计）	需要结合分片路由的场景
数据库自增ID（分片）	低	高	高	低	不推荐，易导致全局ID冲突