MySQL 用 uuid 作为主键会导致“页分裂”，这种影响可以忽略吗？

[erquiasz0825]

如题，MySQL(5.7) 用 uuid 作为主键会导致“页分裂”，这种影响大吗，是否可以忽略？

[zhuweiyou]

snowflake 或 uuid_short

[ZhenShaw]

@elboble 类似雪花算法，不是 uuid

[qaqLjj]

建议采用雪花号，补一个之前做的总结：
UUID 为什么不推荐做索引？
1. 长度太长，int 4 b ，bigint 8 b ，但是 uuid 是 32 位字符串即 32 b ，一个 uuid 索引占用空间是 int 的 8 倍，是 bigInt 的 4 倍，这会导致二分查找遍历的页增多，甚至可能导致 b+ 树的层高变高，并且，每个二级索引都会存储主键 id 用于回表，如果主键太长，整个表的其他索引也会被拖慢
2. 没有顺序，会将顺序写变为随机写，产生多余的页分裂，多余的页缓存失效处理
3. 比较性能不佳，字符串比大小要先查码表再比较，整形直接就比较了

[qaqLjj]

@elboble 我印象中 MongoDB 用的也是类似雪花算法

[adoal]

UUID 没毛病，但是在 MySQL 上用嘛……连原生支持都没有，就像上面有 v 友说的，你打算当 binary 还是 text ？

[realpg]

@erquiasz0825 #3
id 本来也不是必须暴露
在 URL 上，ID 通过一定算法转成 encode 成字符串
查询进到程序 decode 成 ID
自增步长不要设成 1 ，大一点，很难破解

[realpg]

比如 我给你设计个算法
把数据库的 ID 起始设置为 10000001 确保位数不会太短
首先，生成两个随机数字[0-9] 分别为 x 和 y
把 ID 拆分成个位数的数字数组
a b c d e f g h i ...

然后遍历数组，a 乘以 x b 乘以 y 以此类推 奇数偶数
得到的如果是一位数那么前面补 9 ，比如 a=4 ，x=2 4*2=8 则变为 98 因为 9*9=81 不会出现十位数是 9 的情况
结果记为
aa bb cc dd ee ff gg hh ii jj

把这些结果拼接起来得到

aabbccddeeffgghhiijj... 会是结果的两倍长度
然后将 x 和 y 分别插进去一个固定位置 可以多次插入起到混淆作用，自己定个位置
这个定位要基于最前面的位数，也要基于最后面的位数，可以重复
比如结果这么排列 输出一个纯数字字符串
axabbccddeeffgghhiijjkyk
另外，可以定义一个 hash 表，将 0 1 2 3 4 5 6 7 8 9 分别替换成一个字母，因为字母[A-Za-z]比数字多，可以一个数字有随机的多种表示法

最后得到一串莫名其妙的字符串用来传递


decode 时，用同样的表将字符串替换回数字
然后对应位置抽出 x 和 y
然后每两位读取出来，十位数是 9 替换成 0
然后分别按顺序除以 x 和 y 如果不能整除报错

然后拼接起来得到 ID

[CEBBCAT]

uuid 好像出了新版本，可以搜来看看。好像是考量了分布式和递增

[erquiasz0825]

@makelove 用 hashid ，需要一个 key ，这个 key 如果泄露了要更换，之前的 url 是不是就失效了，这很麻烦

[4ark]

前段时间看过一篇关于主键的文章，推荐一下：[《数据库主键一定要自增吗？有哪些场景不建议自增？
》]( http://itindex.net/detail/62310-%E6%95%B0%E6%8D%AE%E5%BA%93-%E4%B8%BB%E9%94%AE)

[4ark]

@4ark markdown 没生效...

[thinkershare]

@makelove 2 倍的 long, 16 字节, 打错了, mysql 用了 char32, 它应该是没提供原生的 uuid 支持

[reneiw]

@Jooooooooo 你说的不是雪花 id 吗？