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

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

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

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

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

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

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

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

```sql
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，而是到处随机写，磁盘和缓存都吃亏。

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

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

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

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

```text
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 那样做字段交换。

```sql
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 万已经够看趋势了）。三种主键各建一张表，同样的写入方式，结果是这样：

| 主键方案 | 写入耗时 | 表空间(data+index) | 观察 |
| ---- | ---- | ---- | ---- |
| BIGINT 自增 | 11 分 20 秒 | 6.1 GB | 顺序写，页分裂少 |
| CHAR(36) UUIDv4 | 38 分 50 秒 | 9.8 GB | 随机写，页分裂多，空间涨约 60% |
| BINARY(16) UUIDv7 | 12 分 05 秒 | 6.4 GB | 近似顺序写，和自增接近 |

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

```sql
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');
```

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

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

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

| 业务形态 | 主键建议 | 理由 |
| ---- | ---- | ---- |
| 单库单表，量可估 | BIGINT 自增 | 最省心，写入最快，空间最小 |
| 分库分表 / 多源导入 / 要防遍历 | BINARY(16) 的 UUIDv7 | 全局唯一，且接近顺序写 |
| 老系统已是随机 UUID | 别硬换主键 | 外键关联一堆，换主键=牵一发动全身 |

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

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

```sql
-- 老表改造：加自增代理主键，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 主键表。

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


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

订单表5000万行，主键自增还是UUID？三种方案写入与空间实测

订单表5000万行，主键到底选自增还是UUID？从InnoDB聚簇索引的插入模型讲起：自增BIGINT为什么顺序写、省空间，UUIDv4的随机主键怎样引发页分裂和空间膨胀，再到既全局唯一又接近顺序写的UUIDv7。用同一套数据把三种主键各建一张表实测，对比写入耗时与表空间，给出分场景选型和老表改造的稳妥做法，也顺带看了金仓KES在行标识与分布式主键上的布局。

编程语言

主键选择决定InnoDB写入性能与空间占用。自增BIGINT顺序写入最快；UUIDv4随机插入致页分裂、空间膨胀60%，写入慢3倍；UUIDv7结合时间戳与随机性，性能接近自增。建议单库单表用自增，分布式选UUIDv7配BINARY(16)，老表可加代理主键过渡。

代码解释

数据库

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

订单表5000万行，主键自增还是UUID？三种方案写入与空间实测-腾讯云开发者社区-腾讯云

订单表5000万行，主键自增还是UUID？三种方案写入与空间实测

订单表5000万行，主键自增还是UUID？三种方案写入与空间实测

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐