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

Question

通过使用string作为主键与实际的uuid类型相比，索引查找是否存在很大的速度差异，特别是如果字符串具有类似于user-94a942de-05d3-481c-9e0c-da319eb69206的前缀(使查找必须遍历5-6个字符才能找到唯一的字符)？

Answer 1

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

UUID是内置于PostgreSQL类型的。它基本上是一个128位整数。它应该像任何其他大整数一样作为索引执行。Postgres没有内置于UUID生成函数中。您可以在数据库上安装各种模块来完成，也可以在客户端上安装。在客户机上生成UUID会将额外的工作(而不是额外的工作)分发到服务器之外。

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

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

通常情况下，这意味着比较的长度是比较的两倍，因为比较的关键是两倍长。但是，UUID通常在前几个字节中是唯一的，因此不需要对整个UUID进行比较就可以知道它们是不同的。长话短说:比较string与二进制UUID不会在实际应用程序中造成明显的性能差异.尽管MySQL UUID是UTF8编码的事实可能会增加成本。

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

Answer 2

UUID的真正问题在于表(或至少是索引)太大，无法在RAM中缓存。当发生这种情况时，需要将“next”uuid存储到(或从)一些不太可能被缓存的随机块中。随着表的增长，这将导致越来越多的I/O。

AUTO_INCREMENT ids通常不会受到I/O增长的影响，因为INSERTs总是位于表的“末尾”，而SELECTs通常在表的末尾。这将导致缓存的有效使用，从而避免IO死亡。

我的http://mysql.rjweb.org/doc.php/uuid讨论了如何使"Type-1“UUID的性能成本更低，至少对于MySQL来说是这样。