Skip to main content

PostgreSQL 使用 UUID 作为主键的总结

  1. PostgreSQL 使用 UUID 作为主键的总结

    https://maciejwalkowiak.com/blog/postgres-uuid-primary-key/

    本文探讨了在 PostgreSQL 数据库中使用 UUID 作为主键的有效方法，以及如何提升性能。

    核心观点：

    ● UUID 作为主键虽然易于生成和在分布式系统中共享，但其长度可能会影响数据库性能，尤其在大型数据库中。
    ● 使用 PostgreSQL 内置的 uuid 数据类型存储 UUID 比使用 text 类型更有效率，原因在于 uuid 类型占用更少的存储空间。
    ● 原始的 UUID 生成方式 (UUID v4) 不利于 B-tree 索引的性能，因为其值是随机的。
    ● 使用 UUID v7 (时间排序的 UUID) 可以显著提高插入性能，因为其值是时间相关的，有利于 B-tree 索引的排序。

    详细总结：

    文章通过实验对比了使用 text 和 uuid 作为主键的性能差异，结果显示 uuid 类型在表大小和索引大小方面更占优势，尤其是在百万级数据量的情况下，这将显著影响数据库的插入和查询效率。

    文中重点说明了使用 uuid 类型的潜在性能问题在于其随机性。B-tree 索引对有序数据操作效率更高。UUID v4 的随机性导致索引无法充分利用，而 UUID v7 的时间排序特性使得其更适合 B-tree 索引。

    性能优化建议：

    ● 使用 uuid 数据类型而不是 text。
    ● 使用 UUID v7 (时间戳 UUID) 来生成主键，以提高 B-tree 索引效率，特别是对于大型数据集和高频插入场景。
    ● 文中建议使用 Java 的 java-uuid-generator 库来生成 UUID v7。

    结论：

    虽然 UUID 作为主键在很多情况下是可接受的，但是为了获得最佳性能，尤其是在大型数据库中，建议使用 UUID v7 并恰当利用 PostgreSQL 的 uuid 数据类型，避免使用 text 来存储 UUID 字符串。文章强调了如果需要选择主键类型，TSID 可能是一个更好的选择，但如果必须使用 UUID，文中提到的优化策略非常重要。

    #DB #DevOps #Doc
    Maciejwalkowiak
    PostgreSQL and UUID as primary key
    PostgreSQL and UUID as primary key
OKHK