分库分表主键咋设

发布时间：2026-09-23 17:29:53 来源：亿速云阅读：102 作者：小樊栏目：数据库

在分库分表场景下，主键设计的核心目标是：全局唯一、趋势递增（可选）、不暴露业务信息、便于路由。下面按常见方案讲清楚。

一、为什么不能用数据库自增 ID？

每个库表各自 AUTO_INCREMENT，会重复
无法保证全局唯一
容易被猜到数据量（安全问题）

❌ 不推荐：单库自增 ID

二、主流主键方案（按推荐程度）

✅ 1. 雪花算法（Snowflake）——最常用

结构（64位）：

1bit(符号) | 41bit(时间戳) | 10bit(机器ID) | 12bit(序列号)

优点

全局唯一
趋势递增（对索引友好）
性能高，不依赖数据库

缺点

依赖时钟（时钟回拨会出问题）
需要规划 workerId

适用

订单、用户、交易等绝大多数场景

✅ 最推荐

✅ 2. UUID / UUIDv7

UUIDv4：随机，无序 ❌（索引效率低）
UUIDv7：带时间戳，趋势递增 ✅

优点

简单，无需中心服务缺点
长度大（36字符）
索引性能略差

适用

日志、非核心表

✅ 3. 号段模式（Segment）

由 ID 生成服务 一次性取一段：

[1~1000] 给服务A
[1001~2000] 给服务B

优点

DB 压力小
可控、可审计

缺点

需要独立服务

代表

美团 Leaf-segment
滴滴 Tinyid

✅ 4. 数据库号段 + 步长（早期方案）

AUTO_INCREMENT = 1, step = 10

库1：1,11,21
库2：2,12,22

❌ 扩展性差，已基本淘汰

三、分库分表时主键 & 路由的关系

⚠️ 主键 ≠ 分片键（sharding key）

常见组合：

主键：snowflake_id
分片键：user_id

order_id = snowflake
分片规则 = user_id % 16

✅ 主键只保证唯一
✅ 分片键决定落在哪张表

四、实战建议（直接抄）

场景	主键方案
高并发业务表	雪花算法
分布式系统	Leaf / Tinyid
日志类	UUIDv7
强一致需求	号段模式

五、避坑总结

✅ 不要用自增
✅ 不要只靠 UUID
✅ 时钟问题要处理
✅ 主键和分片键分开设计

如果你愿意，我可以：

帮你设计具体表结构
按 MySQL / PostgreSQL / ShardingSphere 给示例
帮你算 workerId 分配方案

直接说业务场景就行。

向AI问一下细节