GUID / UUID数据库密钥的优缺点
过去，我曾在许多数据库系统上工作过，如果所有数据库键都是GUID / UUID值，则在数据库之间移动条目将变得更加容易。我已经考虑过几次，但是总是存在一些不确定性，尤其是在性能和无法通过电话读取的URL周围。
是否有人在数据库中广泛使用GUID？这样下去，我将获得什么好处？可能的陷阱是什么？
解决方案
回答
主要优点是我们可以创建唯一的ID，而无需连接到数据库。 ID在全球范围内是唯一的，因此我们可以轻松地组合来自不同数据库的数据。这些看似很小的优势，但过去为我节省了很多工作。
主要缺点是需要更多的存储空间(在现代系统上不是问题)，并且id并不是真正可读的。调试时可能会出现问题。
存在一些性能问题，例如索引碎片。但是这些都是可以解决的(吉米·尼尔森(Jimmy Nillson)的梳子指导：http://www.informit.com/articles/article.aspx?p=25862)
编辑合并了我对这个问题的两个答案
@Matt Sheppard我认为他的意思是我们可以使用不同的GUID复制行作为主键。这是任何种类的代理密钥(不仅仅是GUID)的问题。就像他说的那样，通过向非关键列添加有意义的唯一约束，可以轻松解决此问题。另一种方法是使用自然键，而那些键确实有问题。
回答
如果将GUID用作"唯一标识符"，将来可能会给我们带来很多麻烦，从而使重复的数据进入表中。如果要使用GUID，请考虑在其他列上仍然保持UNIQUE约束。
回答
@马特·谢泼德(Matt Sheppard)：
假设我们有一个客户表。当然，我们不希望客户在表中存在一次以上，否则整个销售和物流部门都会发生混乱(特别是如果有关客户的多行包含不同的信息)。
因此，我们拥有一个唯一标识客户的客户标识符，并确保客户知道该标识符(在发票中)，以便客户和客户服务人员在需要交流时拥有共同的参考。为了保证没有重复的客户记录，我们可以通过客户标识符上的主键或者通过客户标识符列上的NOT NULL + UNIQUE约束向表中添加唯一性约束。
接下来，由于某种原因(我无法想到)，要求我们将GUID列添加到客户表并将其作为主键。如果客户标识符列现在没有唯一性保证，那么我们将在整个组织中寻求将来的麻烦，因为GUID将始终是唯一的。
一些"架构师"可能会告诉我们"哦，但是我们在应用程序层中处理了真正的客户唯一性约束！"。正确的。关于通用编程语言和(尤其是)中间层框架的流行方式始终在变化，并且通常不会使数据库失效。而且很有可能我们需要在不浏览当前应用程序的情况下访问数据库。 ==麻烦。 (但是幸运的是，我们和"建筑师"早已一去不复返了，所以我们将不会在那里清理混乱。)换句话说：请在数据库(以及其他层，如果有)中保持明显的约束。时间)。
换句话说：可能有充分的理由在表中添加GUID列，但是请不要被诱惑降低真实性(== non-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。
回答
为什么没有人提到性能？当我们有多个联接时，所有这些基于讨厌的GUID的性能都将一直传到地板上：(
回答
如果还使用该列作为聚簇索引，则要考虑使用GUIDS作为主键的另一个小问题(一种相对常见的做法)。由于GUID的性质无论如何都不是按顺序开始的，因此我们将在插入时受到打击，因此插入时它们将是页面拆分等。这是系统是否要具有较高IO的考虑因素...
