MySQL主键设计最佳实践：BIGINT自增与UUIDv7对比

大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

上个月新项目评审，开发说主键用UUID，理由是"永远不冲突、分布式友好"。我说先别急着定，主键在InnoDB 里不只是个唯一标识，它决定了整张表怎么存、写得多快、占多大空间。吵不出结果，我干脆从线上导了一张 5000 万行的订单表结构，分别用自增 BIGINT、UUIDv4、UUIDv7 建了三张测试表灌数据。结论一句话：单库单表，自增最省心；要全局唯一，选 UUIDv7，别再用随机 UUID 当主键。下面就来讲清楚为什么。

一、主键在 InnoDB 里，不只是"唯一标识"

很多开发以为主键就是用来唯一区分行的。在 InnoDB 里，它的角色重得多：主键就是聚簇索引，整行数据直接存在主键索引的叶子节点上。

这意味着两件事。第一，插入顺序由主键值决定。新行的主键比已有的大，就往 B+ 树的右半边插；主键是随机的，就可能插到树中间任意位置。第二，所有二级索引的叶子节点都存着主键值，主键越大、越占空间，每个二级索引都被拖大。

所以主键的选择，直接决定写入顺不顺、页会不会频繁分裂、表和索引占多少空间。这不是"随便选一个唯一值"的事。

二、自增 BIGINT：为什么默认是它

自增主键的最大优势，是写入的顺序性。新主键永远比旧的大，插入永远发生在 B+ 树最右侧的叶子页。页满了就在右边开新页，不会去中间挤占，页分裂最少，写入基本是顺序 IO。

CREATE TABLE orders (
  id BIGINT NOT NULL AUTO_INCREMENT,
  user_id BIGINT NOT NULL,
  amount DECIMAL(12,2) NOT NULL,
  created_at DATETIME NOT NULL,
  PRIMARY KEY (id)
) ENGINE=InnoDB;

BIGINT 只占 8 字节，主键小，二级索引也跟着小。这是 InnoDB 最省心、最省空间的主键形态。

它的缺点在分布式和多源场景。两个库各自自增，主键会撞；要按订单号对外暴露，业务量一眼看穿，也容易被遍历爬取；多套系统数据要合并导入时，自增值互相冲突，得先规划号段。所以自增不是万能，要看业务边界在哪。

顺便补一句，主键不等于唯一的行标识方式。评审那天我们还顺嘴聊到，不同数据库对"怎么定位一行"给的答案并不一样。KES这边最常用的就是 SERIAL/BIGSERIAL 自增主键，和前面 BIGINT 一个路子；要范围扫、偏运维的场景它会上 ROWID，藏在隐藏列里物理存一份，自动带 B-tree 唯一索引。所以单库单表选自增这套逻辑是共通的，换个库照样成立，选型最终看的还是场景。

三、UUIDv4：最大的错不是"字符串"，是"随机"

UUIDv4 的问题，很多人归咎于"它是字符串、占空间"。这只是表象。真正的坑是它随机。

随机主键意味着新行可能插到 B+ 树任意位置。目标叶子页满了怎么办？页分裂，把一半数据挪到新页。随机插入让分裂到处发生，分裂后的页通常只有约一半是满的，留下的空洞越来越多，表空间随之膨胀。写入也不再是顺序 IO，而是到处随机写，磁盘和缓存都吃亏。

-- 别这样存UUID：36字符，又大又随机
id CHAR(36) NOT NULL PRIMARY KEY

更隐蔽的是，即使你把 UUID 压缩成 BINARY(16) 存，体积问题解决了，随机性还在，页分裂和随机写一点没少。所以压缩存储只解决空间，解决不了"插入顺序"这个核心问题。这也是为什么我不建议拿 UUIDv4 当主键，哪怕存成二进制。

四、UUIDv7：把时间戳塞进去，顺序回来了

UUIDv7 是新的 UUID 标准（RFC 9562），思路很直接：把生成时间戳放进 UUID 的前 48 位，单位是毫秒。同一时刻之后生成的 UUID，值一定更大。

UUIDv7 的 128 位布局
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       unix_ts_ms (48位)                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      unix_ts_ms续(16位)      | 版本 |       rand_a            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 变体 |                      rand_b                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

前 6 个字节是时间戳，按时间递增，插到 InnoDB 里就接近顺序写，页分裂和随机写的问题基本没了。后 10 个字节是随机数，保证全局唯一。等于同时拿到了"自增的顺序写"和"UUID 的全局唯一"。

存储上要配合 BINARY(16)，别存成 CHAR(36)。v7 的时间戳本来就在头部，直接存二进制就是时间有序，不需要像 v1 那样做字段交换。

CREATE TABLE orders_v7 (
  id BINARY(16) NOT NULL,
  user_id BIGINT NOT NULL,
  amount DECIMAL(12,2) NOT NULL,
  created_at DATETIME NOT NULL,
  PRIMARY KEY (id)
) ENGINE=InnoDB;

需要提醒的是，MySQL 自带的 UUID() 函数生成的是 v1 风格的 UUID，不是 v7。UUIDv7 目前主要靠应用侧生成，再以 BINARY(16) 写入。生成时要注意，别在应用里拼出字符串再转，直接生成 16 字节的二进制，省一次转换也省空间。

五、实测：同一张表，三种主键

原理讲完，上数据。我从线上导了订单表结构，灌了 1000 万行做对照（标题说的 5000 万是线上那个量级，测试机灌 1000 万已经够看趋势了）。三种主键各建一张表，同样的写入方式，结果是这样：

UUIDv4 比自增慢了 3 倍多，表空间多了六成。UUIDv7 和自增几乎打平，表空间也只多一点点。差距的根源，就是第二节说的那个"插入顺序"。

SELECT table_name,
       ROUND(data_length/1024/1024,1)  AS data_mb,
       ROUND(index_length/1024/1024,1) AS index_mb
FROM information_schema.tables
WHERE table_schema = 'test'
  AND table_name IN ('orders_auto','orders_uuid_v4','orders_uuid_v7');

数值是测试机上的绝对值，不同磁盘、不同并发会有出入，但相对趋势是稳定的：随机主键写慢、占大，顺序主键写快、占小。这一条，换什么机器都成立。

六、怎么选，老表又怎么改

落到选择上，我按场景给个判断。

老表最忌讳上来就"把 UUID 主键改成自增"。订单表关联了一堆子表，外键都指着这个主键，改了主键，所有关联列和索引全要跟着动，风险极大。

更稳的路子是加一个自增的代理主键，让它当聚簇索引，原来的 UUID 降级成普通唯一索引保留。这样写入顺序有了，老代码用 UUID 查也能走唯一索引。代价是随机 UUID 写进二级唯一索引时，索引页仍会有分裂，但二级索引的写入成本远低于聚簇索引，比现状好太多。

-- 老表改造：加自增代理主键，UUID保留为唯一键
ALTER TABLE orders
  ADD COLUMN id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY FIRST,
  ADD UNIQUE KEY uk_order_uuid (order_uuid);

如果你连 UUID 的空间都想省，把 CHAR(36) 统一转成 BINARY(16) 存，用 UUID_TO_BIN 转换，能再砍掉一半索引体积。但记住，这只是空间优化，随机性带来的写放大还在。

再补一句，分库分表的全局唯一，不是只有 UUIDv7 一条路。之前做选型时我了解过 KES 的分布式序列服务，靠号段标记来保证全局唯一，配上分布式集群还能横向扩、带故障转移。量级真上来了，这是个可以评估的方向。

迁移这边也有省事的，它的 KDTS 工具能自动认出 MySQL 的 AUTO_INCREMENT 列，直接映射成自增类型，老表主键不用重写，手工活少一大截。所以哪天真要做多源合并或者换库，别急着全押 UUID，这类更贴合的方案也值得先看看。

避坑清单

别拿 CHAR(36) 存 UUID 当主键。36 字符又大又随机，页分裂、随机写、二级索引膨胀全占了。真要 UUID，至少用 BINARY(16)。这一点改完，空间能省一半，但随机写救不回来，所以更该考虑 v7。

自增主键别在分库分表或多源导入里裸用。两个库各从 1 开始自增，合并必撞。要么用 UUIDv7，要么规划号段，别等撞了再补。多源导入时还要先清掉源表主键，再让目标库重新分配。

老表改主键，先看外键再动手。主键被多少子表引用，改起来就是多大的工程。稳妥做法是加代理自增列当新主键，UUID 降级成唯一索引，别一上来就动原主键。改完记得重建相关二级索引，不然旧索引还指着老结构。

我的判断

主键这事，开发爱 UUID 是因为它"永远不冲突"，DBA 爱自增是因为它"写入最顺"。两边都没错，错的是把"分布式场景的需求"套到了所有场景上。

我的原则很简单：单库单表，用自增，别为不存在的分布式提前买单。真要分布式、要全局唯一，就用 UUIDv7 配 BINARY(16)，它把随机 UUID 最大的坑——写入乱序——补上了。技术选型没有银弹，但至少别把 UUIDv4 当主键这个雷，再踩一次。

你现在的表主键用的啥？有没有被随机主键的页分裂坑过？评论区聊聊，我猜不少 DBA 都见过"表不大、空间却大得离谱"的 UUID 主键表。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋