使用字符串类型与uuid类型对UUID主键的性能影响是什么？

Question

对于主键使用string与实际uuid类型相比，索引查找的速度差异很大，特别是如果字符串具有类似user-94a942de-05d3-481c-9e0c-da319eb69206的前缀（使得在获得独特的东西之前，查找必须遍历5-6个字符？

Answer 1

这是一种微观优化，在您达到巨大规模之前不太可能导致真正的性能问题。使用最适合您设计的钥匙。那就是说，这是细节......

UUID is a built in PostgreSQL type。它基本上是一个128位整数。它应该像任何其他大整数一样作为索引执行。 Postgres没有内置的UUID生成功能。您可以在数据库上安装各种模块，也可以在客户端上执行。在客户端上生成UUID会将额外的工作（没有多少额外工作）分配给服务器。

MySQL没有内置的UUID类型。相反，有一个UUID function可以生成UUID作为十六进制数字的字符串。因为它是一个字符串，UUID键可能会有性能和存储命中。它也可能会干扰复制。

字符串UUID会更长;十六进制字符每字节仅编码4位数据，因此十六进制字符串UUID需要256位来存储128位信息。这意味着每列更多的存储和内存会影响性能。

通常这意味着比较的时间是两倍，因为比较的密钥是两倍长。但是，UUID在前几个字节中通常是唯一的，因此不需要比较整个UUID就知道它们是不同的。简而言之：比较字符串与二进制UUID不应该在实际应用程序中造成明显的性能差异......虽然MySQL UUID是UTF8编码的事实可能会增加成本。

在PostgreSQL上使用UUID很好，它是一个内置类型。 MySQL的UUID密钥实现非常不完整，我会远离它。当你在它的时候，远离MySQL。

Answer 2

当表（或至少索引）太大而无法缓存在RAM中时，UUID的真正问题就出现了。发生这种情况时，需要将“下一个”uuid存储到随机块中（或从中获取） 缓存。随着表的增长，这会导致越来越多的I / O.

AUTO_INCREMENT ids 通常不会遭受I / O增长，因为INSERTs始终位于表格的“结尾”，SELECTs 通常集群接近结尾。这样可以有效地使用缓存，从而避免死亡。

我的UUID blog讨论了如何使“Type-1”UUID的性能降低成本，至少对MySQL来说是这样。