关于 MySQL 建表主键用自增还是 uuid 的问题

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

这是一个创建于 1096 天前的主题，其中的信息可能已经有所发展或是发生改变。

关于 MySQL 建表主键 id 字段的类型，目前有这几种：

一个自增数字作为主键 id
一个无序的 uuid 作为 id
一个有序的 uuid 作为 id
一个业务 uuid （无序）作为 id ，一个自增字段 incr_id

InnoDB 引擎，主键 id 有序能利用其优势。

第 1 种，对于敏感的数据，容易根据 id 增长暴露增量；

第 2 种，没利用到 B+ Tree 的特性；

第 3 种，要引入 snowflake 等算法生成器；

第 4 种，其实是第 2 种的变体，加一个 incr_id 自增字段，在分页的时候用到

大家讨论一下，在 2021 年，那种主键 id 类型是推荐的？

主键

uuid

字段

MySQL

36 条回复 • 2021-12-14 10:14:11 +08:00

xuanbg

2021-12-13 10:21:51 +08:00

雪花 ID

Fly4J

2021-12-13 10:28:19 +08:00

snowflake

ylz

2021-12-13 10:39:30 +08:00

第一个的问题可以用 https://hashids.org/

love2020

2021-12-13 10:41:06 +08:00

在使用 InnoDB 存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键

TUNGH

2021-12-13 10:49:48 +08:00

要么自增,要么雪花

initdada

2021-12-13 10:52:28 +08:00

分布式 ID 生成器参考 Tinyid 、Leaf

Feiex

2021-12-13 10:53:22 +08:00

既然业务 id 敏感，我推荐 3 ，加上防止回退做成 sdk 就好了，大家一起用也不用关系细节

mokeyjay

2021-12-13 11:09:35 +08:00

UUID 在实践中遇到了一些麻烦的问题
所以目前我们在建表和逻辑代码中用自增主键 id ，但这个 id 对外展示前会经过 #3 提到的 hashids 哈希后展示

onhao

2021-12-13 11:19:58 +08:00

我们是网文行业，采用自增方式，然后发现败的一塌糊涂，不过在哪里摔倒就在哪里爬起来，我们还是坚持采用自增，不过对自增 ID 做了对应的处理，通过自定义函数，算出一个不重复的字符串，然后创建一个视图。完美解决。

lichao

2021-12-13 11:21:38 +08:00

@mokeyjay 分享一下，什么样的麻烦？

FawkesV

2021-12-13 11:34:13 +08:00

雪花 ID 吧

chengyiqun

2021-12-13 11:45:38 +08:00

@lichao 无序 uuid 容易造成索引重排, 写入性能很低.
而自增的, 只要追加到索引的最后即可.

zzzmj

2021-12-13 11:48:59 +08:00

自增 id 再加一个 uid 索引=。=

815979670

2021-12-13 11:56:52 +08:00

用 UUID 的话可以考虑使用 `UUID_TO_BIN()` MySQL8.0 新增函数，将 uuid 转为二进制，转换后是一个 varchar(16) 的值。（做主键即能代替 id 自增，又能解决 uuid 做主键性能不好的问题）

tabris17

2021-12-13 11:58:01 +08:00

> 第 1 种，对于敏感的数据，容易根据 id 增长暴露增量；

自增 ID+hashids 加密就行了

chotow

2021-12-13 12:42:57 +08:00

分享一个从 V 友那里学到的，使用 MySQL 自带函数 UUID_SHORT： /t/802473 #1

makelove

2021-12-13 12:56:30 +08:00

uuid 太大了，不但在主表上且每个索引的每个项都会包含这个 uuid 指回主表,简直过于浪费内存
没有业务必要自增足够好了

onhao

2021-12-13 13:07:33 +08:00

可以参考下，我们的方案自定义函数+视图的方法 https://wuhao.pw/archives/282/

Numbcoder

2021-12-13 13:40:26 +08:00

把 MySQL 换成 PG ，就没这些月经问题了

FallenTy

2021-12-13 14:26:54 +08:00

自增 ID 作为数据库主键，再用 uuid 作为接口查询参数，自增 ID 仅用于数据库关联查询

NBY

2021-12-13 14:57:54 +08:00

@Numbcoder 严重同意
PG 这么好用为啥不用 PG 呢

imnpc

2021-12-13 15:00:11 +08:00

建议使用自增 ID 然后使用 hashid 对外输出和解密

niubee1

2021-12-13 15:27:14 +08:00

MySQL 用 uuid 有性能问题，最好是自增

whoosy

2021-12-13 15:27:57 +08:00

用自增 uuid

fangcan

2021-12-13 15:44:56 +08:00

用自增 id ，但是 id 不暴露可以么？暴露业务 id

nigulasida

2021-12-13 16:22:57 +08:00

@Numbcoder 换乘 PG ，为什么主键就不需要考虑这个问题了呢？
可以用 uuid ？

nigulasida

2021-12-13 16:27:50 +08:00

@NBY

换成 PG ，为什么主键就不需要考虑这个问题了呢？
可以用 uuid ？

elboble

2021-12-13 16:35:16 +08:00

自增吧，mongo 要花力气才能做个自增的 id ，mysql 自带的还不用？

Jooooooooo

2021-12-13 16:55:36 +08:00

雪花是如此简单为啥不用呢.

nekoneko

2021-12-13 17:38:40 +08:00

id + uuid
后端逻辑用 id
前后端交互用 uuid

0x208

2021-12-13 18:46:48 +08:00

雪花目前用的挺舒服

codespots

2021-12-13 18:47:55 +08:00

@elboble 同意，用 MongoDB 的时候，一些场景比如用户 id 之类的，必须用类似自增 id 这样的 id ，就得费劲巴拉地区实现一个的时候，非常想念 mysql

zoharSoul

2021-12-13 19:05:30 +08:00

@onhao #9 败的一塌糊涂什么意思?

Huelse

2021-12-13 20:04:43 +08:00

我们是主键自增 ID ，在系统内部关联查询等时也用这个 ID ，
给用户等外部查询时是 hashid 或 uuid ，系统内部不会去用

onhao

2021-12-13 23:09:49 +08:00

@zoharSoul 盗版采集直接根据 ID 来采集我们最新的作品。

zhangyl

2021-12-14 10:14:11 +08:00

雪花，或者自增
雪花的话，如果和前端有交互，bigint 类型有失精问题（末尾几位会变成 0 ），可以改为字符串