GUID / UUID数据库密钥的优缺点

过去，我曾在许多数据库系统上工作过，如果所有数据库键都是GUID / UUID值，则在数据库之间移动条目将变得更加容易。我考虑过几次，但是总是存在一些不确定性，尤其是在性能和​​无法通过电话读取的URL周围。

是否有人在数据库中广泛使用GUID？这样下去，我将获得什么优势？可能的陷阱是什么？

优点：

• 可以离线生成它们。
• 使复制变得微不足道（与int相对，这真的很难）
• ORM通常像他们
• 在所有应用程序中都是唯一的。因此，我们可以在应用程序（也为GUID）中使用来自CMS（GUID）的PK，并且知道我们永远不会发生冲突。

缺点：

• 使用空间较大，但空间便宜
• 无法按ID订购以获取插入订单。
• 可以在URL中看起来很丑陋，但实际上，WTF是否正在将REAL DB密钥放入URL中？（这一点在下面的评论中有争议）
• 手动调试比较困难，但并不难。

就个人而言，我在任何体面大小的系统中都将它们用于大多数PK，但是我受到了在整个位置复制的系统的“培训”，因此我们不得不拥有它们。YMMV。

我认为重复数据是垃圾-无论您如何获得重复数据。我工作过的地方通常都不会使用代理键。我们确实使用类似于WordPress的系统：

• 行的唯一ID（GUID /其他）。永远对用户不可见。
• 公共ID是从某个字段一次生成的（例如标题-使其成为文章的标题）

更新： 因此，这个获得了很多+1，我想我应该指出GUID PK的一个很大缺点：聚簇索引。

如果您有很多记录，并且在GUID上有聚集索引，则插入性能将很糟糕，因为您可以在项目列表中的随机位置（即重点）插入插入，而不是在结尾处插入（这是快速的）

因此，如果您需要插入性能，则可以使用auto-inc INT，如果要与其他人共享（例如，通过URL向用户显示），则可以生成GUID。

@马特·谢泼德（Matt Sheppard）：

假设您有一个客户表。当然，您不希望客户在表中存在一次以上，否则在您的销售和物流部门中会发生很多混乱（特别是如果有关客户的多行包含不同的信息）。

因此，您有一个可以唯一标识客户的客户标识符，并确保客户知道该标识符（在发票中），以便客户和客户服务人员在需要交流时有共同的参考。为了保证没有重复的客户记录，您可以通过客户标识符上的主键或通过客户标识符列上的NOT NULL + UNIQUE约束向表中添加唯一性约束。

接下来，由于某种原因（我无法想到），要求您将GUID列添加到客户表并将其作为主键。如果客户标识符列现在没有唯一性保证，那么您将在整个组织中寻求将来的麻烦，因为GUID将始终是唯一的。

一些“架构师”可能会告诉您“哦，但是我们在应用程序层中处理了真正的客户唯一性约束！”。对。关于通用编程语言和（尤其是）中间层框架的流行方式一直在变化，并且通常不会使数据库失效。而且很有可能您将需要在不浏览当前应用程序的情况下访问数据库。==麻烦。（但是幸运的是，您和“建筑师”早已一去不复返了，因此您不会在那里清理混乱。）换句话说：如果在数据库中（以及在其他层中，如果有时间）。

换句话说：可能有充分的理由在表中添加GUID列，但是请不要被诱惑降低真实性（== non-GUID）信息中的一致性的野心。

为什么没有人提到性能？当您有多个联接时，所有基于这些讨厌的GUID的性能都将一直传到地板上：(

如果将GUID用作“唯一标识符”，将来可能会给您带来很多麻烦，从而使重复的数据进入表中。如果要使用GUID，请考虑在其他列上仍然保持UNIQUE约束。

主要优点是您可以创建唯一的ID，而无需连接到数据库。ID是全球唯一的，因此您可以轻松地组合来自不同数据库的数据。这些看似很小的优势，但过去为我节省了很多工作。

主要缺点是需要更多的存储空间（在现代系统上不是问题），并且ID并不是真正可读的。调试时可能会出现问题。

存在一些性能问题，例如索引碎片。但是这些都是可以解决的（吉米·尼尔森（Jimmy Nillson ）的梳子指导：http : //www.informit.com/articles/article.aspx? p = 25862 ）

编辑合并了我对这个问题的两个答案

@Matt Sheppard我认为他的意思是您可以使用不同的GUID复制行作为主键。这是任何种类的代理密钥（不仅仅是GUID）的问题。就像他说的那样，通过向非关键列添加有意义的唯一约束，可以轻松解决此问题。另一种方法是使用自然键，而那些键确实有问题。

如果还使用该列作为聚簇索引，则要考虑使用GUIDS作为主键的另一个小问题（一种相对常见的做法）。由于GUID的性质无论如何都不是按顺序开始的，因此您将在插入时受到打击，因此插入时它们将是页面拆分等。这是系统是否要具有较高IO的考虑因素...

主键编号与指南

GUID作为主键的成本（SQL Server 2000）

神话，GUID与自动增量（MySQL 5）

这真的是您想要的。

UID优点

• 在每个表，每个数据库，每个服务器中都是唯一的
• 允许轻松合并来自不同数据库的记录
• 允许在多个服务器之间轻松分发数据库
• 您可以在任何地方生成ID，而不必往返于数据库
• 大多数复制方案仍然需要GUID列

GUID缺点

• 它比传统的4字节索引值大4倍；如果您不小心，可能会对性能和存储造成严重影响
• 调试麻烦（其中userid ='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'）
• 生成的GUID应该是部分顺序的，以实现最佳性能（例如，SQL 2005上的newsequentialid（））并允许使用聚簇索引

有一件事情没有真正解决，即使用随机（UUIDv4）ID作为主键会损害主键索引的性能。无论您的表是否围绕键聚集，都会发生。

RDBM通常在称为BTree的结构中确保主键的唯一性，并确保通过键进行查找，该结构是具有较大分支因子的搜索树（二进制搜索树的分支因子为2）。现在，顺序整数ID将导致刀片出现只是一个树的一侧，剩下的大部分叶节点不变。添加随机UUID将导致插入操作在整个索引上拆分叶节点。

同样，如果存储的数据主要是临时数据，则通常需要访问最新数据并将其与大多数数据合并。使用随机UUID时，模式将不会从中受益，并且会命中更多的索引行，从而需要内存中更多的索引页。如果使用顺序ID，则如果最需要最新数据，则热索引页将需要较少的RAM。