你要是纠结 key 的问题还不如用 mongodb ，那个 key 算是完美的

更重要的原因是页分裂造成的 io

你这两个数据场景的主键不应该是 uid 加时间么？使用 uuid 的目的是什么？

bigint 呗，也才 8k ，至少省一半空间，效率也好点。18446744073709551615 ，能把这撑爆？

1 楼的缓存吧，redis 就行

内部业务主键，最好是用自增的 64 位 int ，也就是 BIGINT：
https://dev.mysql.com/doc/refman/8.4/en/integer-types.html

有些场景需要把主键传到前端，产品经理不希望别人通过调试来看出主键值，于是还需要加个 hash 。而 UUID 可以在这里一步到位，这也是为啥很多公司喜欢 UUID 的根源所在。

uuid 的主要问题是大小无序叶分裂，但是其实问题不大，我们这现在有 70 多 w 数据 uuid 的表。没发现有啥异常。