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

Question

对于主键与实际的uuid类型，使用string对于索引查找是否存在很大的速度差异，特别是如果字符串具有类似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的时候避开MySQL。

Answer 2

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

AUTO_INCREMENT IDS 通常不吃亏的是I/O的增长，因为INSERTs总是在表中的“结束”，并接近尾声SELECTs通常集群。这导致缓存的有效使用，从而避免了IO的死亡。

我的UUID blog讨论了如何使“Type-1”UUID的性能成本更低，至少对于MySQL而言。