对 UUID 主键使用字符串类型与 uuid 类型对性能有何影响？

Question

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

Answer 1

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

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

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

Answer 2

这是一种微优化，在达到大规模之前不太可能导致真正的性能问题。使用最适合您的设计的键。也就是说，这是详细信息...

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 时，请远离它。