主键 on 牛哥聊技术

逻辑主键还是业务主键？数据库主键设计的取舍与最佳实践

Tue, 25 Nov 2025 15:30:00 +0800

写在前面

数据库主键看似简单——但选错了能让一个表"永远改不动":

业务编码当主键 → 业务规则一变全表 rebuild
UUID 当主键 → 索引性能差、空间膨胀
自增 ID → 跨库迁移血泪
雪花 ID → 时钟回拨能让你怀疑人生

新人常困惑——到底该选哪个？本文讲清五种主流方案（自增 BIGINT、UUID v4、UUID v7、雪花 ID、业务键作主键）的优劣、取舍、典型场景。

一、概念先分清：逻辑主键 vs 业务主键

逻辑主键

和业务无关的"内部标识"——纯技术存在。

自增 BIGINT
UUID
雪花 ID

特点：业务永远改不到它，因为它没有业务含义。

业务主键

业务上有意义的字段——天然唯一。

用户表用 username
订单表用 order_no
商品表用 sku_code

特点：业务可能要求改格式、改前缀、改长度。

这两个概念是冲突的——主键应该用哪一种？答案不是非黑即白。

二、五种主流方案

方案 1：自增 BIGINT 逻辑主键（推荐默认）

1
2
3
4
5
6


CREATE TABLE user (
 id BIGINT PRIMARY KEY AUTO_INCREMENT,
 username VARCHAR(64) UNIQUE,
 name VARCHAR(64),
 -- ...
);

优点：

写入性能极好——InnoDB 按主键聚簇，递增 ID 永远 append
索引体积小——8 字节
JOIN 高效——整数比较快
业务编码可以单独建索引、独立演化

缺点：

跨库迁移痛——两库的自增 ID 必然冲突
单库瓶颈——发号依赖单一数据库
暴露业务规模——id=1234567 攻击者能猜测总量
不适合分布式场景

适用：单库或简单分库（按业务键分库）的小到中型项目。80% 的业务表用这个。

方案 2：UUID

1
2
3
4


CREATE TABLE user (
 id BINARY(16) PRIMARY KEY,
 -- ...
);

优点：

全球唯一——零中心化
跨库无冲突
不暴露业务规模

缺点：

写入性能差——UUID 无序，每次插入都可能引发页分裂
空间大——16 字节，char(36) 文本形式更是 36 字节
索引差——B+ Tree 上散列严重
JOIN 慢——字符串比较开销大

用 UUID 一定要 BINARY(16) 不能 CHAR(36)——16 字节 vs 36 字符，索引和 JOIN 性能差距巨大。

适用：离线生成 ID 的场景（移动端先生成、再上传）、对中心化发号有强烈反感的场景。多数 Web 业务不推荐。

方案 3：UUID v7（时间有序 UUID）

UUID v7（2024 RFC 9562 标准）解决了 UUID 的写入性能问题——前 48 位是毫秒时间戳：

1

018D2DA1-7000-7XXX-XXXX-XXXXXXXXXXXX

优点：

时间递增——索引友好
全球唯一——分布式无冲突

缺点：

仍然 16 字节，比 BIGINT 大
会暴露生成时间（精确到毫秒）——和雪花 ID 一样，敏感场景需评估
工具/框架支持还在普及中

这是 2024 后比 v4 更值得用的 UUID 形式——多数语言库已经支持。

方案 4：雪花 ID（Snowflake）

Twitter 设计的分布式 ID 算法——64 位结构：

1
2


| 1 bit | 41 bits | 10 bits | 12 bits |
| 符号 | 时间戳（毫秒） | 工作机器 ID（5 bit dc + 5 bit machine） | 序列号 |

10 bit 机器位 Twitter 原版就拆成 5 bit datacenter + 5 bit worker，最多支持 32 个数据中心 × 32 台机器 = 1024 节点。

优点：

64 位 BIGINT——和自增 ID 一样紧凑
时间递增——索引友好
分布式无中心
高吞吐（每节点每毫秒 4096 个）

缺点：

时钟回拨问题——服务器时钟跳回会重复 ID
机器 ID 分配——上千节点时管理麻烦
还是暴露业务速率（每毫秒能生成多少）

适用：分布式系统的标准选择。美团 Leaf、百度 UidGenerator 都是改进版。

方案 5：业务键作主键（不推荐）

1
2
3
4


CREATE TABLE user (
 username VARCHAR(64) PRIMARY KEY,
 -- ...
);

优点：

表自描述
少一个字段

缺点：

业务规则一变就完蛋（比如 username 长度要扩展）
VARCHAR 主键聚簇索引大、慢
关联表的外键也要 VARCHAR——空间和性能双爆炸
业务编码可能为空（早期数据没填）→ 主键不能为空 → 全表数据迁移

多数 OLTP 场景都不推荐这么做——除非表很小且业务键真正稳定不变。

三、决策树

flowchart TD
 Start([单库还是分布式?])
 Start -->|单库| Small{规模小?}
 Start -->|分布式| Snow[雪花 ID 或 UUID v7]
 Small -->|是| Auto[自增 BIGINT]
 Small -->|否，将来要分库| Snow

90% 的场景按这个流程决定：

小型系统、单库 → 自增 BIGINT
可能分库或一开始就分布式 → 雪花 ID
离线生成 / 强分布式无中心 → UUID v7

四、生产级雪花 ID 的实现要点

朴素雪花算法在生产里有不少坑——成熟方案要解决：

1. 时钟回拨

绝对禁止时钟跳回——可能导致 ID 重复。处理方案：

启动时检查时钟，跳了就拒绝启动
运行时检测，跳了就等回到原点再发号（短暂阻塞）
改进版用 bit 当回拨标志位

2. 机器 ID 分配

朴素方案要在配置文件里写死 worker_id——上千节点时是地狱。生产方案：

ZooKeeper / etcd 自动分配
进程启动时主动注册
退出时主动释放

3. 数据中心 ID

如上所述 Twitter 原版就把 10 bit 拆成 5+5；如果你的部署只有一个 DC，可以把 datacenter 位让渡给 worker 位，扩展到 1024 台单 DC 节点。

4. 序列号回滚

朴素方案每毫秒序列号从 0 开始——容易在毫秒边界 burst 时浪费。改进：

上一毫秒的序列号末位作为下一毫秒的起点（散列写入）

5. 实战推荐

直接用：

美团 Leaf：github.com/Meituan-Dianping/Leaf
百度 UidGenerator：github.com/baidu/uid-generator

不要自己手写——这些库覆盖了所有边界。

五、对外暴露的"业务编码"

无论用什么主键，对外暴露通常都不直接用主键——而是用业务编码：

1
2
3
4
5


CREATE TABLE order (
 id BIGINT PRIMARY KEY AUTO_INCREMENT,
 order_no VARCHAR(32) UNIQUE NOT NULL, -- 对外
 -- ...
);

order_no 用规则生成：

1

ORD202511250001234 (前缀 + 日期 + 序号)

为什么"对外用 order_no、对内用 id"？

对外不暴露业务规模——order_no 看不出实际订单数
支持改格式——order_no 改前缀不影响内部关联
可读——客服发"订单号 ORD…"，比"id=12345"友好

这是国内大多数生产系统的标准姿势。

六、几个常见反模式

反模式 1：业务编码当主键 + 加 `_old` 字段做迁移

业务规则改了 → 加 username_old 字段保留老的 → 后续查询要 WHERE username = ? OR username_old = ? ——永远的技术债。

反模式 2：UUID 用 char(36)

1

id CHAR(36) PRIMARY KEY -- ❌

应该用 BINARY(16)——空间和性能差距巨大。

反模式 3：自增 ID 暴露给前端

前端 URL 里 ?orderId=12345 ——攻击者枚举可以拿到所有订单。用业务编码或者对 ID 做混淆（如 hashids 库）。

反模式 4：复合主键

1

PRIMARY KEY (user_id, order_id)

复合主键麻烦多——外键关联痛苦、ORM 支持不好、加新维度时改表复杂。永远用单字段主键 + 唯一索引表达组合唯一。

反模式 5：自增 + UUID 双主键

“我两个都要！"——同时维护两个 ID 维护成本高、容易产生不一致。单一真理来源（single source of truth）——只有一个主键。

七、性能数据对比

10 亿行表，单条 INSERT 的耗时（实测大致比例）：

	写入耗时	索引大小	JOIN 速度
BIGINT 自增	1×	1×	1×
雪花 ID	1×	1×	1×
BINARY(16) UUID v7	1.2×	2×	1.2×
BINARY(16) UUID v4	5×（页分裂严重）	2×	1.2×
CHAR(36) UUID	8×	4×	5×
VARCHAR 业务键	6×	3×	4×

差距在大数据量场景被无限放大。

八、实战 Checklist

设计新表时按这个清单：

主键用 BIGINT 自增 / 雪花 ID
业务编码加唯一索引 但不当主键
VARCHAR 主键不允许（除非超小表）
UUID 用 BINARY(16) + v7 不要 v4 / char(36)
关联表外键用主键 ID，不要用业务编码
对外 API 用业务编码，不暴露主键
重要表的业务编码生成有规则（前缀 + 日期 + 序号 / hashids）
分布式场景用雪花 ID，不要自己撸

九、关于"零号 ID”

很多人争论 ID 应该从 0 还是 1 开始——约定俗成是从 1 开始：

id = 0 在 Java / Go 里是基本类型默认值——容易混淆"未设" vs “设为 0”
业务上"用户 0"听起来怪
一些 ORM 把 id = 0 视为"新对象未保存"

让 ID 从 1 开始是最少踩坑的约定。

小结

把全文压一句：

主键应该是业务无关的、稳定的、紧凑的——业务编码独立另存，对外用编码、对内用主键。这是数据库表能长期演化的基础。

工程纪律：

新表默认 BIGINT 自增——简单可靠
分布式上雪花 ID
UUID 用 v7 + BINARY(16)
绝不用 VARCHAR 业务键作主键
业务编码加唯一索引 + 对外暴露
主键不暴露给前端

把这些做对，你的表能跑 10 年——而不是一年后就要做"主键迁移"这种最痛的事。

关联用 ID 还是 CODE：数据库主键与外键设计实践

Wed, 15 Mar 2017 15:00:00 +0800

一个常被反复争论的设计问题

每个数据库表都有一个自增 id 主键——这件事几乎没人会争。但外键到底应该引用 id 还是引用业务编码（code），争论从未停止。

举个最常见的例子：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


-- 方案 A：用 ID 关联
CREATE TABLE orders (
 id BIGINT PRIMARY KEY,
 status_id BIGINT, -- 关联 order_status.id
 ...
);

-- 方案 B：用 CODE 关联
CREATE TABLE orders (
 id BIGINT PRIMARY KEY,
 status_code VARCHAR(32), -- 关联 order_status.code
 ...
);

注：示例里用 orders 而不是 order——order 是 SQL 保留字，直接拿来当表名要么报语法错误，要么必须加反引号 `order`。

哪种好？两派都各有铁粉，争论起来谁也说服不了谁。本文把两种方案的优劣、适用边界、工程取舍讲清楚——不给标准答案，但讲清楚什么场景该选什么。

第一原则：先区分两类外键

讨论这个问题前必须先把"外键"分成两大类——它们的处理逻辑完全不同：

关联类外键：链接两个业务实体。例如 order.user_id 指向 user.id、order_item.product_id 指向 product.id
枚举类外键：链接到字典/枚举。例如 order.status 表示订单状态、user.gender 表示性别

flowchart LR
 O1[order] -->|user_id| User[user]
 O1 -->|status_code| Dict[order_status
字典]
 O2[order_item] -->|product_id| Product[product]

关联类外键和枚举类外键，结论不一样。下面分开讲。

一、关联类外键：建议用 ID

order.user_id 这种"指向另一个业务实体"的外键，强烈建议用 ID 关联——也就是数据库自增主键或雪花 ID。

为什么用 ID

1. ID 是不变的，业务编码可能变

user_no = "U20170315001" 这种"业务用户编号"看起来像永久标识，但业务发起人随时可能要求改格式：

“把所有用户编号前缀从 U 改成 A，因为合并了 A 公司的系统。”

如果 100 张表都用 user_no 关联，改一次格式要重写 100 张表的引用——可能涉及上亿行数据。如果用 ID，业务编码爱怎么变怎么变。

2. 数字索引比字符串索引快

数据库的 B+ Tree 索引中，整数 8 字节、字符串 32 字节起步。整数索引的 IO 和比较都快得多——尤其在 join 大量数据时差距明显。

1
2
3
4
5


-- 整数 join
WHERE order.user_id = user.id

-- 字符串 join
WHERE order.user_no = user.user_no

千万级数据下，前者比后者快 30%-50% 不是稀奇事。

3. ID 是单调递增的，写入友好

InnoDB 是按主键聚簇存储的——递增 ID 写入时永远是 append，热点页只有一个。如果用业务编码（不一定单调），写入时容易引发**页分裂 **，影响写性能。

4. 不暴露业务信息

ID 是个"无意义数字"，不会泄漏业务规模。order.id = 9876543 攻击者拿到也猜不出实际订单量；但 order.order_no = "ORD-20170315-00001" 一看就知道当天第几单。

但 ID 也不是完美

1. 跨库迁移痛

ID 是数据库自增，两个库的数据合并时 ID 必然冲突——常见做法是用雪花 ID 或一开始就用 UUID。

2. 读起来不友好

日志里看到 user_id=12345 你要去查另一张表才知道是谁。所以业务对外的 API 通常还是返回 user_no——内部 ID + 外部 code 双轨制。

二、枚举类外键：建议用 CODE

订单状态、性别、城市编码这种"指向字典"的外键，反过来——建议用 CODE 关联。

为什么用 CODE

1. 可读性极强

1
2
3
4


-- 用 ID
SELECT * FROM order WHERE status_id = 3;
-- 用 CODE
SELECT * FROM order WHERE status_code = 'PAID';

不用 join 字典表都能看懂"已支付"。线上排查问题时这个差别非常大。

2. 字典基本不会改

order_status 这种字典——PAID、SHIPPED、COMPLETED——一旦确定，几乎不会变（业务有变化也是新增，不是修改）。code 不会改的前提下，ID 的"不变性优势"就消失了。

3. 跨系统一致

字典经常要给前端、第三方对接、数据导出。PAID 比 3 通用得多——前端不用维护"3=已支付"的对照表，直接看 code 写逻辑。

4. 代码层面更清爽

业务代码用枚举 + 字符串 code 是天然契合：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public enum OrderStatus {
 UNPAID("UNPAID"),
 PAID("PAID"),
 SHIPPED("SHIPPED"),
 COMPLETED("COMPLETED");

 private final String code;
 OrderStatus(String code) { this.code = code; }
}

// SQL 里直接 status_code = 'PAID'
// Java 里 status == OrderStatus.PAID
// 前端直接 status === 'PAID'

如果用 ID，代码里到处是 status_id == 3 这种魔法数字，可读性差，加新状态时容易和已有 ID 撞。

5. 字典表本身也得有

国内项目还有种做法是根本不建字典表，code 直接写在代码枚举里。这有它的优势——一致性强、没有"代码和数据库不同步"的问题，但缺点是 修改要发版，前端没法动态拉取选项。

工程上常见做法：

简单字典直接代码枚举
需要后台管理、能配置的字典建表（status_code 作为 PK 或唯一索引）

三、混用：一种实用模式

很多项目其实是混用——业务实体用 ID 关联，枚举用 code：

1
2
3
4
5
6
7


CREATE TABLE orders (
 id BIGINT PRIMARY KEY,
 order_no VARCHAR(32) UNIQUE, -- 业务编号，对外用
 user_id BIGINT, -- 关联 user.id（关联类）
 status_code VARCHAR(32), -- 关联 order_status.code（枚举类）
 ...
);

这是一种"按字段类型选方案"的混合姿势，比"全 ID"或"全 CODE"都更贴合实际。

四、第三种争论：UUID / 雪花 ID

Long 自增 ID 适合单库，分布式场景常被替换为 UUID 或雪花 ID。

方案	优点	缺点
自增 ID	紧凑、有序、写入友好	单库限制、跨库迁移痛
UUID	全局唯一、无中心化	二进制 16 字节 / 文本 36 字符、v4 无序、写入页分裂、读取慢
雪花 ID	紧凑（Long）、有序、分布式	时钟回拨问题、需要部署机器号

关联类外键用什么主键，CODE 关联问题不大。但用 UUID 时务必走 BINARY(16) 存储而不是 CHAR(36) ——前者只占一半空间且索引性能高得多（不止一倍）。

五、外键约束：要不要加 FK constraint

讨论"用 ID 还是 CODE"时，常常顺带聊另一个问题——要不要在数据库层面建外键约束：

1

ALTER TABLE order ADD CONSTRAINT fk_user FOREIGN KEY (user_id) REFERENCES user(id);

国内绝大多数生产项目不建外键约束，原因：

性能影响：每次写入都要校验外键，高并发下是负担
分库分表后约束失效：跨库 FK 是不可能的
运维痛点：表的清理、备份、迁移都被外键卡住

业内主流做法是——逻辑外键（应用层保证一致性，数据库不强制）。这意味着：

表设计上仍然要有"外键"概念
命名规范要清晰：user_id / product_id 这种命名让人一眼看出关联
数据一致性靠应用代码 + 单测覆盖

六、实战建议

flowchart TD
 Start([这个外键关联什么?])
 Start --> Type{业务实体 or 枚举字典?}
 Type -->|业务实体| ID[用 ID 关联
同时保留 业务编码 字段对外]
 Type -->|枚举字典| CHANGE{字典变化频率?}
 CHANGE -->|几乎不变| CODE[用 CODE，不依赖字典表]
 CHANGE -->|偶尔会改| BOTH[code 关联，但字典建表持久化]

具体几条建议：

业务实体外键用 ID——user_id、product_id、order_id
枚举/字典外键用 CODE——status_code、type_code
xxx_no / xxx_code 字段建唯一索引——业务上对外暴露但 DB 关联用 ID
生产环境基本都不加 FK 约束——逻辑外键 + 应用层校验
不要把"自增 ID"暴露给前端——容易暴露业务规模 + 不好做加密短链
跨库场景上雪花 ID 不要 UUID——写入性能差距很大

七、一些反例

反例 1：`user_no` 当外键

某项目用 U20170315001 这种用户编号当所有外键。三年后业务并购，要把所有 U 开头的用户改成 A 开头——全表 update + 全部关联表 update，停服 12 小时。

教训：业务编号永远可能改格式。

反例 2：状态用 ID

订单状态字典表里 1=未付款、2=已付款、3=已发货。某天产品提需求：“把’已付款’拆成’部分付款’和’全额付款’"。开发以为只要在字典加一条， 结果全代码搜 status_id == 2 漏改了三处——线上有"全额付款的订单被识别为部分付款”。

教训：枚举用数字 ID 容易让代码里有魔法数字。

反例 3：用业务编码当主键

order_no 设为 order 表的主键——单字段、有序、看似优雅。但：

VARCHAR 主键聚簇索引大、IO 多
业务编码格式偶尔要改（前缀、长度）→ 主键变化引发整表 rebuild
子表关联用 VARCHAR(32) 占空间多

教训：主键应当稳定、无意义、紧凑——bigint id 是最佳形态。

小结