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

【问题标题】：Optimizing PostgreSQL performance when using UUIDs as primary keys使用 UUID 作为主键时优化 PostgreSQL 性能
【发布时间】：2023-02-21 16:53:06
【问题描述】：

我知道与顺序整数值相比，使用 UUID 作为主键可能会对性能产生不利影响。

我在我的机器上做了一些测试，发现各种操作（在相当大的范围内）确实慢了很多。

我有一个包含连续整数主键的表并插入了 2000 万条记录——这在 1 分 55 秒内完成。然后我删除该表并再次创建相同的表，但这次使用 UUID 主键。插入 2000 万条记录耗时 6 分 44 秒。

目前，我正在使用 uuid 数据类型配置主键列，默认值设置为 gen_random_uuid() - 因此 UUID 是在数据库级别而不是应用程序级别生成的。

我想知道是否有任何建议可以优化 UUID 作为主键的使用。例如，如果 PK 是一个整数，但另一个（索引）字段包含一个 UUID，专门用于公开曝光，这会有帮助吗？

我也对可能存在的非顺序 PK 的其他想法持开放态度，同时性能更高。

（我还没有处理这种规模的数据；这更像是一个理论问题。）

【问题讨论】：

添加具有另一个唯一索引的另一列肯定会使事情变得更慢，而不是更快。顺便说一句：在 Postgres 中没有 AUTOINCREMENT 这样的东西
改用 ulid
@a_horse_with_no_name 好吧，我学到了一些新东西。我使用的 GUI 在类型列表中有“自动增量”，但我只是注意到它实际创建的是一个默认值为 nextval('untitled_table_id_seq'::regclass) 的 int4 字段。感谢您指出！
详细说明@AsadAwadia 所说的内容，使用 ulid 更好，因为它们是可排序的。此处规范：github.com/ulid/spec 随机 UUID 会破坏性能，因为 btree 索引在数据可以排序时效果最好。不幸的是，ULID 不是本机的，但您可以在周围找到人们的功能。

【解决方案1】：

UUID 比序列生成的键慢。你只需要接受它，没有办法解决它。出于这个原因，只有在有令人信服的理由时才使用 UUID，例如密钥是在数据库外部生成的，或者需要在多个数据库中是唯一的。

对此in my article 有一些更深入的讨论。

【讨论】：

【解决方案2】：

虽然 this post 专注于 MySQL，但所提供的解决方案可以轻松地应用于任何其他数据库。通过重新排列 UUID 使与时间相关的组件成为值的第一部分，它显示出显着的性能提升。

【讨论】：