GUID/UUID 数据库键的优缺点

优点：

可以离线生成它们。

使复制变得微不足道（与 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，如果您想与其他人共享它，则生成一个 GUID（即，在 URL 中将其显示给用户）

---

为什么没有人提到性能？当您有多个连接时，所有这些都基于这些讨厌的 GUID，性能将通过地板，一直在那里:(

---

@马特谢泼德：

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

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

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

一些“架构师”可能会告诉您“哦，但我们在应用层处理真正的客户唯一性约束！”。正确的。关于通用编程语言和（尤其是）中间层框架的时尚一直在变化，并且通常永远不会超过您的数据库。而且很有可能您在某些时候需要在不通过当前应用程序的情况下访问数据库。 == 麻烦。 （但幸运的是，你和“架构师”早已不在，所以你不会在那里收拾烂摊子。）换句话说：一定要在数据库中保持明显的约束（如果你有的话，在其他层也一样）时间）。

换句话说：将 GUID 列添加到表中可能有充分的理由，但请不要相信这会降低您在真实（==非 GUID）信息中保持一致性的野心。

---

主要优点是您可以在不连接到数据库的情况下创建唯一 ID。并且 id 是全球唯一的，因此您可以轻松组合来自不同数据库的数据。这些似乎是很小的优势，但在过去为我节省了很多工作。

主要缺点是需要更多的存储空间（在现代系统上不是问题），并且 id 并不是人类可读的。这可能是调试时的问题。

存在一些性能问题，例如索引碎片。但是这些很容易解决（jimmy nillson 的梳理指南：http://www.informit.com/articles/article.aspx?p=25862）

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

@Matt Sheppard 我认为他的意思是您可以复制具有不同 GUID 的行作为主键。这是任何类型的代理键的问题，而不仅仅是 GUID。就像他说的那样，通过向非键列添加有意义的唯一约束很容易解决。另一种方法是使用自然键，而那些有真正的问题..

---

如果 GUID 被用作“uniqifiers”，那么 GUID 将来可能会给您带来很多麻烦，让重复的数据进入您的表中。如果您想使用 GUID，请考虑在其他列上仍然保持 UNIQUE-constraints。

---

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

---

primary-keys-ids-versus-guids

The Cost of GUIDs as Primary Keys（SQL Server 2000）

Myths, GUID vs. Autoincrement（MySQL 5）

这真的是你想要的。

UUID 优点

每个表、每个数据库、每个服务器都是唯一的

允许轻松合并来自不同数据库的记录

允许跨多个服务器轻松分布数据库

您可以在任何地方生成 ID，而不必往返于数据库

大多数复制方案无论如何都需要 GUID 列

GUID 缺点

它比传统的 4 字节索引值大 4 倍；如果您不小心，这可能会对性能和存储产生严重影响

调试麻烦（其中 userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}'）

生成的 GUID 应该是部分顺序的，以获得最佳性能（例如，SQL 2005 上的 newsequentialid()）并启用聚集索引

---

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

RDBMs通常保证主键的唯一性，并保证通过一个键进行查找，在一个叫做BTree的结构中，它是一个分支因子很大的搜索树（二叉搜索树的分支因子为2）。现在，一个连续的整数 ID 将导致插入仅发生在树的一侧，而大部分叶节点保持不变。添加随机 UUID 将导致插入在整个索引中拆分叶节点。

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

---

优点：

UUID 值在表和数据库之间是唯一的。这就是为什么它可以合并两个数据库或分布式数据库之间的行。

UUID 通过 url 比整数类型数据更安全。如果通过 url 传递 UUID，攻击者无法猜测下一个 id。但是如果我们传递 10 等整数类型，那么攻击者可以猜测下一个 id 是 11，然后是 12，依此类推。

UUID 可以离线生成。

---

到目前为止没有提到的一件事：UUID 使分析数据变得更加困难

至少对于网络应用程序，通常使用 url 中的 id 访问资源，例如 stackoverflow.com/questions/45399。如果 id 是一个整数，这两者

提供有关问题数量的信息（即 2008 年 9 月 5 日，提出了第 45,399 个问题）

提供一个杠杆点来迭代问题（当我将其增加 1 时会发生什么？我打开下一个问题）

从第一点开始，我可以将问题中的时间戳和数字结合起来，以分析提出问题的频率以及随时间变化的情况。这在像 Stack Overflow 这样具有公开信息的网站上并不重要，但是，根据上下文，这可能会暴露敏感信息。

例如，我是一家为客户提供权限门控门户的公司。地址是 portal.com/profile/{customerId}。如果 id 是整数，您可以通过定期查询 lastKnownCustomerCount + 1 并检查结果是 404 - NotFound（客户不存在）还是 403 - Forbidden（客户确实存在，但您无权查看）。

UUID 的非顺序性质缓解了这些问题。这并不是为了防止分析，但它是一个开始。

---