› 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
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
这是一个创建于 1111 天前的主题，其中的信息可能已经有所发展或是发生改变。
关于 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 类型是推荐的？
 |
1
xuanbg 2021-12-13 10:21:51 +08:00
雪花 ID
|
 |
2
Fly4J 2021-12-13 10:28:19 +08:00
snowflake
|
 |
3
ylz 2021-12-13 10:39:30 +08:00  3
第一个的问题可以用 https://hashids.org/
|
 |
4
love2020 2021-12-13 10:41:06 +08:00 5
在使用 InnoDB 存储引擎时，如果没有特别的需要，请永远使用一个与业务无关的自增字段作为主键
|
 |
5
TUNGH 2021-12-13 10:49:48 +08:00
要么自增,要么雪花
|
 |
6
initdada 2021-12-13 10:52:28 +08:00
分布式 ID 生成器 参考 Tinyid 、Leaf
|
 |
7
Feiex 2021-12-13 10:53:22 +08:00
既然业务 id 敏感，我推荐 3 ，加上防止回退做成 sdk 就好了，大家一起用也不用关系细节
|
 |
8
mokeyjay 2021-12-13 11:09:35 +08:00
UUID 在实践中遇到了一些麻烦的问题
所以目前我们在建表和逻辑代码中用自增主键 id ，但这个 id 对外展示前会经过 #3 提到的 hashids 哈希后展示 |
 |
9
onhao 2021-12-13 11:19:58 +08:00
我们是网文行业， 采用自增方式， 然后发现败的一塌糊涂， 不过在哪里摔倒就在哪里爬起来， 我们还是坚持采用自增， 不过对自增 ID 做了对应的处理， 通过自定义函数，算出一个不重复的字符串，然后创建一个视图。完美解决。
|
 |
11
FawkesV 2021-12-13 11:34:13 +08:00
雪花 ID 吧
|
 |
12
chengyiqun 2021-12-13 11:45:38 +08:00
@lichao 无序 uuid 容易造成索引重排, 写入性能很低.
而自增的, 只要追加到索引的最后即可. |
 |
13
zzzmj 2021-12-13 11:48:59 +08:00
自增 id 再加一个 uid 索引=。=
|
 |
14
815979670 2021-12-13 11:56:52 +08:00
用 UUID 的话可以考虑使用 `UUID_TO_BIN()` MySQL8.0 新增函数，将 uuid 转为二进制，转换后是一个 varchar(16) 的值。（做主键即能代替 id 自增，又能解决 uuid 做主键性能不好的问题）
|
 |
15
tabris17 2021-12-13 11:58:01 +08:00
> 第 1 种，对于敏感的数据，容易根据 id 增长暴露增量；
自增 ID+hashids 加密就行了 |
 |
17
makelove 2021-12-13 12:56:30 +08:00
uuid 太大了，不但在主表上且每个索引的每个项都会包含这个 uuid 指回主表,简直过于浪费内存
没有业务必要自增足够好了 |
|
18
onhao 2021-12-13 13:07:33 +08:00
可以参考下， 我们的方案 自定义函数+视图的方法 https://wuhao.pw/archives/282/
|
 |
19
Numbcoder 2021-12-13 13:40:26 +08:00 1
把 MySQL 换成 PG ，就没这些月经问题了
|
 |
20
FallenTy 2021-12-13 14:26:54 +08:00
自增 ID 作为数据库主键，再用 uuid 作为接口查询参数，自增 ID 仅用于数据库关联查询
|
 |
22
imnpc 2021-12-13 15:00:11 +08:00
建议使用自增 ID 然后 使用 hashid 对外输出和解密
|
 |
23
niubee1 2021-12-13 15:27:14 +08:00
MySQL 用 uuid 有性能问题，最好是自增
|
 |
24
whoosy 2021-12-13 15:27:57 +08:00
用自增 uuid
|
 |
25
fangcan 2021-12-13 15:44:56 +08:00
用自增 id ，但是 id 不暴露可以么？ 暴露业务 id
|
 |
26
nigulasida 2021-12-13 16:22:57 +08:00
@Numbcoder 换乘 PG ，为什么主键就不需要考虑这个问题了呢？
可以用 uuid ？ |
|
27
nigulasida 2021-12-13 16:27:50 +08:00
|
 |
28
elboble 2021-12-13 16:35:16 +08:00
自增吧，mongo 要花力气才能做个自增的 id ，mysql 自带的还不用？
|
 |
29
Jooooooooo 2021-12-13 16:55:36 +08:00
雪花是如此简单为啥不用呢.
|
 |
30
nekoneko 2021-12-13 17:38:40 +08:00
id + uuid
后端逻辑用 id 前后端交互用 uuid |
 |
31
0x208 2021-12-13 18:46:48 +08:00
雪花目前用的挺舒服
|
 |
32
codespots 2021-12-13 18:47:55 +08:00
@elboble 同意，用 MongoDB 的时候，一些场景比如用户 id 之类的，必须用类似自增 id 这样的 id ，就得费劲巴拉地区实现一个的时候，非常想念 mysql
|
 |
34
Huelse 2021-12-13 20:04:43 +08:00
我们是主键自增 ID ，在系统内部关联查询等时也用这个 ID ，
给用户等外部查询时是 hashid 或 uuid ，系统内部不会去用 |
 |
36
zhangyl 2021-12-14 10:14:11 +08:00
雪花，或者自增
雪花的话，如果和前端有交互，bigint 类型有失精问题（末尾几位会变成 0 ），可以改为字符串 |
Select Language