PostgreSQL中如何高效使用UUID主键？
内容提要
本文介绍了在PostgreSQL中高效使用UUID作为主键的方法，包括使用uuid数据类型存储UUID、UUID v7的概念和插入速度、以及使用TSID作为主键类型的建议。
延伸解读
文本存储UUID的代价
文章通过实验对比了text和uuid类型存储UUID主键的性能差异。在1000万行数据下，使用text类型的表比uuid类型大54%，索引大85%。这是因为UUID是128位数据，而text类型需要额外存储长度信息和字符编码。更大的表和索引意味着PostgreSQL需要更多页来存储数据，当索引超过可用内存时，必须从磁盘加载，从而降低查询和插入性能。因此，应始终使用uuid类型而非text存储UUID。
UUID v7对B树索引的优化
B树索引对有序值效果最佳，而UUID v4是伪随机值，插入时会导致索引页频繁分裂和随机I/O。UUID v7按时间排序，新值总是更大，因此插入时总是追加到索引末尾，减少了页分裂和随机写入。文章实验显示，插入UUID v7的速度是UUID v4的两倍。在Java中可以使用java-uuid-generator库生成UUID v7。对于高流量或大型数据集，这种优化能显著提升插入性能。
TSID：更优的主键选择
尽管UUID v7提升了插入性能，但文章指出UUID由于长度问题，仍然不是主键的最佳选择。作者建议考虑TSID（Time-Sorted Unique Identifiers），它由Vlad Mihalcea维护。TSID结合了时间排序和更短的存储长度，可能提供更好的性能。如果必须使用UUID，则应采用uuid类型和UUID v7。但需注意，这些优化对小型数据集或低流量应用影响不大，对于大型系统，从一开始就选择合适的主键类型可以避免后期迁移的挑战。
Q&A
在PostgreSQL中使用UUID作为主键有什么优势？
UUID易于生成和共享，能够保证唯一性，适合分布式系统使用。
PostgreSQL中UUID的存储方式是什么？
PostgreSQL提供专门的UUID数据类型，存储单个UUID值需要16个字节。
UUID v7与UUID v4有什么区别？
UUID v4是伪随机值，而UUID v7是按时间排序的值，更适合B-Tree索引。
使用UUID v7作为主键有什么性能优势？
使用UUID v7可以提高INSERT语句的性能，插入速度是UUID v4的两倍。
在PostgreSQL中，使用文本类型存储UUID的缺点是什么？
使用文本类型存储UUID会导致表和索引的大小显著增加，影响性能。
在选择主键时，UUID是否是最佳选择？
尽管UUID有其优势，但它仍然不是主键的最佳选择，建议考虑使用TSID。
