使用UUID作为主键时，优化PostgreSQL性能

Question

我对数据库还比较新，并且一直在考虑在我的项目中使用 UUID 作为主键，但是我读到了一些东西，让我对性能更加感兴趣。

目前，我正在使用 uuid 数据类型，其默认值设置为 gen_random_uuid()。

首先，我想知道: UUID 作为主键会造成性能下降吗？

如果有的话...

• 是否有任何优化提示，例如，如果 PK 是顺序的，但另一个字段包含 UUID，特别是用于公开展示，是否有帮助？
• 是否有任何类似的替代方法可能更具性能？

（我还没有处理任何可观度量规模的数据；这更多是一个理论问题。）

- Obvious_Grapefruit

---

添加另一列与另一个唯一索引肯定会使事情变慢，而不是更快。顺便说一下：在Postgres中没有“AUTOINCREMENT”这样的东西。 - user330315

使用 ULID 替代。 - Asad Awadia

@a_horse_with_no_name 好的，我学到了新东西。我正在使用的GUI在类型列表中有“自动增量”，但我刚刚注意到它实际上创建的是一个带有默认值为nextval('untitled_table_id_seq'::regclass)的int4字段。感谢您指出这一点！ - Obvious_Grapefruit

为了阐述@AsadAwadia所说的，使用ulid更好，因为它们是可排序的。规范在这里：https://github.com/ulid/spec 随机UUID会破坏性能，因为B树索引在数据可以排序时效果最佳。不幸的是，ULID不是本地的，但你可以找到人们的函数来解决。 - Optimum

Answer 1

UUID（通用唯一标识符）比由序列生成的键慢。你不得不接受这一点，没有什么办法可以避免。因此，只有在具有强制性的原因时才使用 UUID，例如键是在数据库外生成或需要在多个数据库中保持唯一。

在我的文章中有更深入的讨论。

- Laurenz Albe

Answer 2

虽然这篇文章的重点是MySQL，但所提供的解决方案同样适用于任何其他数据库。通过重新排列UUID以使与时间相关的组件成为值的第一部分，它展示了显著的性能提升。

- Matthew Setter