停止在你的数据库中使用UUID

停止在你的数据库中使用UUID

引用

CSDN

1.

https://blog.csdn.net/qq449245884/article/details/139485341

在数据库中唯一标识行的最常见方法之一是使用UUID字段。然而，这种方法带来了需要注意的性能问题。本文将讨论在使用UUID作为数据库表中的键时可能出现的两个性能问题。

什么是UUID？

UUID代表通用唯一标识符（Universally Unique Identifier）。UUID有很多版本，但在本文中，我们将讨论最流行的版本：UUIDv4。

以下是UUIDv4的一个示例：

问题1 —— 插入性能

当向表中插入新记录时，必须更新与主键相关的索引以保持最佳查询性能。索引是使用B+树数据结构构建的。

对于UUIDv4来说，重新平衡过程变得非常低效。这是因为UUID的固有随机性，使得保持树的平衡变得更加困难。当你的数据规模扩大时，需要重新平衡数百万个节点，这显著降低了使用UUID键的插入性能。

问题2 —— 更高的存储需求

我们考虑一个带有自动递增整数键的UUID的大小：

• 自动递增整数每个值消耗32位，而UUID每个值消耗128位。
• 每行UUID的存储空间是整数的4倍。
• 此外，大多数人以人类可读的形式存储UUID，这意味着UUID每个值可能消耗多达688位。这是整数的约20倍。

让我们通过模拟一个现实的数据库来评估UUID如何实际影响存储。我们将使用Josh Tried Coding的示例表：

这个示例使用了Neon PostgreSQL数据库。

• 表1将包含100万行UUID。
• 表2将包含100万行自动递增整数。

以下是结果，让我们逐一分析每个统计数据：

总表大小：考虑到两个表的大小，UUID表大约是整数表的2.3倍！

ID字段大小：单个UUID字段需要比等效整数字段多9.3倍的存储空间！

ID列大小：排除每个表中的其他属性时，UUID和整数列之间的大小差异为3.5倍！

结论

UUID是确保表中记录唯一性的好方法。然而，这些问题在大规模使用时尤为明显，因此对于大多数人来说，UUID实际上不会导致明显的性能下降。尽管这些问题在大规模使用时普遍存在，但重要的是要了解在表中使用UUID的影响，并确保数据库设计的优化。