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

[erquiasz0825]

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

[erquiasz0825]

补充：uuid 非自增

[Rumble66]

非常大, 最好用有序自增整形做主键.
不仅是插入性能差, 查询性能也差.

[erquiasz0825]

@Rumble66
1. 如果 id 不想对外暴露怎么办？
2. 为什么也会影响查询性能呢？

[thinkershare]

@erquiasz0825 因为按照分页查询时候, 数据会分散到不同的页, GUID 这种如果要作为主索引, 一定要支持自增, 否则插入 /查询都会有不小的性能损失. GUID 有自增的算法版本

[Jooooooooo]

设计一个毫秒时间戳+机器码+随机数的方案, 全本地操作, 也不复杂.

[cxxlxx]

@erquiasz0825 关于第二点，可以使用这个 进行转换 https://hashids.org/

[cheng6563]

换 ksuid

[haoooooo]

雪花

[potatowish]

用数据库自增保存原始 id ，对外用 hashid 包装

[makelove]

id 不想暴露的方法多了，比如上面的 hashid ，哪怕另建一列 uuid 当公开 id 都比用 uuid 作主键好，因为所有索引项都会包含主键，用 uuid 浪费内存和硬盘

[ToBeHacker]

看你是不是需要有序遍历或展示吧

[erquiasz0825]

@makelove
“另建一列 uuid 当公开 id 都比用 uuid 作主键好”

那么根据 uuid 查找实体吗？还是根据 uuid 查到 id ，再根据 id 查找实体？

[lessMonologue]

@erquiasz0825 根据主键 id 查实体，然后把这个实体对应的 uuid 返回出去吧。OP 应该去看看 InnoDB 的主键索引建立过程。

[thinkershare]

@makelove uuid 并不浪费内存, UUID 在很多数据库的实现中使用了 8 个字节, 也就是 2 倍 long 的长度, uuid 完全可以做到高效, 除非性能特别重要, 而且单个表数据极大, 否则选择 uuid 是一个很不错的选择, 性能是一个需要基准测试问题. 绝大部分系统的性能问题都不会因为你使用了 UUID 而导致. 反而我非常推荐使用 UUID 作为 id.

[cheng6563]

@thinkershare MySQL 没有原生 UUID 类型，要存 UUID 要么用 binary 要么用 varchar ，前者难用后者废空间。而且 UUID v4 也确实不太适合用 B+树来索引。

[LostPrayers]

如果是 JAVA 用 MybatisPlus 库，主键可以选 IdType.ASSIGN_ID (雪花算法的 bigint), 或者用自增 IdType.Auto (数据库自增)

[Soar360]

我用多主键比较多

[ipwx]

我不是 MySQL 玩家。PostgreSQL 如果用 uuid 肯定是为了在可预见的将来，对象互相引用的 ID 不会发生改变。我觉得这是 UUID 最大的作用。

[elboble]

Mongodb 的 id 好像是 uuid 但是还是有序递增的

[makelove]

@thinkershare 8 字节的 uuid ？给个链接让我开开眼？