使用 UUID 或 GUID 作为主键有什么缺点？

Question

我想建立一个分布式系统。我需要将数据存储在数据库中，使用UUID或GUID作为某些表的主键会很有帮助。我认为这是这种设计的一个缺点，因为 UUID/GUID 非常大并且它们几乎是随机的。另一种方法是使用自动递增的 INT 或 LONG。

使用 UUID 或 GUID 作为我的表的主键有什么缺点？

我可能会使用 Derby/JavaDB（在客户端上）和 PostgreSQL（在服务器上）作为 DBMS。

Answer 1

这取决于您的生成功能和决赛桌的大小

GUID 旨在成为全球唯一标识符。正如Postgres 8.3 文档中所讨论的，没有普遍适用于生成这些标识符的方法，但 postgreSQL 确实提供了一些更有用的候选者。

从您的问题的范围和脱机写入的需要来看，您已经非常巧妙地将除 GUID 之外的任何东西都排除在外，因此没有其他方案的补偿优势。

从功能的角度来看，密钥长度在任何类型的现代系统上通常都不是问题，这取决于读取次数和表的大小。作为替代方法，离线客户端可以在没有主键的情况下批处理新记录，并在重新连接时简单地插入它们。由于 postgreSQL 提供“串行”数据类型，因此如果客户端可以对数据库执行简单的写入，则它们永远不需要确定 ID。

Answer 2

还有一个建议 - 永远不要使用 GUID 作为聚集索引的一部分。GUID 不是连续的，因此如果它们是聚集索引的一部分，每次插入新记录时，数据库都需要重新排列其所有内存页以找到正确的插入位置，以防 int(bigint) 自动递增，它将只是最后一页。

现在，如果我们看看一些数据库实现：1.) MySQL - 主键是集群的，没有改变行为的选项 - 建议在这里根本不使用 GUID 2.) Postgres，MS-SQL - 你可以将 GUID 设为主键非聚集，并使用另一个字段作为聚集索引，例如 autoincrement int。