我曾经在许多数据库系统上工作过，如果所有数据库键都是guid/uuid值，那么在数据库之间移动条目就容易得多。我已经考虑过沿着这条路径走几次了，但是总是有一些不确定性，特别是关于性能和不可通过电话读取的URL。

是否有人在数据库中广泛使用guid？这样做会有什么好处？可能的陷阱是什么？

优势：

• 可以脱机生成。
• 使复制变得简单(与int相反，它使复制变得非常困难)
• ORM通常喜欢他们
• 跨应用程序的唯一性。所以我们可以在应用程序中使用CMS(guid)中的pk(guid)，并且知道我们永远不会发生冲突。

缺点：

• 空间使用量大，但空间便宜(ER)
• 无法按ID排序以获取插入顺序。
• 在URL中看起来很难看，但实际上，wtf是在URL中放置一个真正的db键吗？？
• 手动调试更难，但也不难。

就我个人而言，我在任何一个相当大的系统中使用它们，但是我在一个在各地复制的系统上接受了"培训"，所以我们必须拥有它们。YMMV。

我认为重复数据的事情是垃圾-你可以得到重复的数据，无论你怎么做。代孕钥匙通常不适合我在哪里工作。不过，我们确实使用了类似WordPress的系统：

• 行的唯一ID(guid/whatever)。用户不可见。
• 公共ID从某个字段生成一次(例如标题-使其成为文章的标题)

更新：所以这个得到+1’ed很多，我想我应该指出guid-pk的一个大缺点：聚集索引。

如果您有很多记录，并且在一个guid上有一个聚集索引，那么当您在项目列表中的任意位置(即要点)插入时，您的插入性能将很糟糕，而不是在末尾(即快速插入)。

因此，如果您需要插入性能，可以使用auto inc int，如果您想与其他人共享它，可以生成一个guid(即，在URL中显示给用户)。

@ Matt Sheppard：

假设你有一张顾客桌。当然，您不希望客户不止一次出现在表中，否则整个销售和物流部门都会出现很多混乱(尤其是当客户的多行包含不同的信息时)。

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

接下来，由于某种原因(我想不起来)，您需要向customer表中添加一个guid列，并将其作为主键。如果"客户标识符"列现在没有唯一性保证，那么您将在整个组织中请求未来的问题，因为guid始终是唯一的。

一些"架构师"可能会告诉您"哦，但是我们在我们的应用层中处理真正的客户唯一性约束！"对。关于通用编程语言和(特别是)中间层框架的时尚一直在变化，而且通常不会超出数据库的实际使用范围。而且，在某些情况下，您很有可能需要访问数据库而不必经过当前的应用程序。=麻烦。(但幸运的是，您和"架构师"早就不在了，所以您不会在那里清理这些混乱。)换句话说：在数据库中(以及其他层，如果您有时间的话)要保持明显的约束。

换言之：向表中添加guid列可能是有充分理由的，但请不要掉以轻心，因为这样会降低您在真实(=non-guid)信息中保持一致性的野心。

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

主要缺点是需要更多的存储空间(在现代系统中不是问题)，并且ID不是真正的人类可读的。调试时这可能是一个问题。

存在一些性能问题，如索引碎片。但是这些都是容易解决的(JimmyNillson的combinguids:http://www.informit.com/articles/article.aspx？p＝25862)

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

@MattSheppard我想他是说你可以用不同的guid复制行作为主键。这是任何类型的代理键的问题，而不仅仅是guid。正如他所说，通过向非键列添加有意义的唯一约束，很容易解决这个问题。另一种选择是使用一把自然钥匙，而那些钥匙确实有问题。

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

如果将guid用作"uniqifier"，让复制的数据进入表中，那么将来guid可能会给您带来很多麻烦。如果要使用guid，请考虑在其他列上仍然保持唯一的约束。

如果您还将该列用作聚集索引(一种相对常见的做法)，那么还需要考虑将guid用作主键的另一个小问题。由于guid的性质，插入时不会按顺序开始，因此插入时它们将是分页符等。只是需要考虑的一点，如果系统将有高IO…

主键ID与guid

作为主键的guid的成本(SQL Server 2000)

神话，guid与autoincrement(mysql 5)

这是你真正想要的。

UID PROS

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

GUID CONS

• 它比传统的4字节索引值大4倍之多；如果不小心，这可能会对性能和存储产生严重影响。
• 调试繁琐(其中userid='bae7df4-ddf-3rg-5ty3erf456as10')
• 为获得最佳性能(例如，SQL 2005上的newSequentialID())和启用聚集索引，生成的guid应该是部分连续的。

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

RDBMS通常确保主键的唯一性，并确保通过键进行查找，这种结构称为btree，它是一种具有较大分支因子的搜索树(二进制搜索树的分支因子为2)。现在，一个连续的整型ID将导致插入只发生在树的一侧，使大多数叶节点保持不变。添加随机UUID将导致插入将整个索引的叶节点拆分。

同样，如果存储的数据大部分是暂时的，那么通常情况下，需要访问最新的数据并将其与最新的数据连接起来。使用随机UUID，模式将不会从中受益，并且会命中更多的索引行，因此需要在内存中使用更多的索引页。对于顺序ID，如果最新的数据是最需要的，那么热索引页将需要更少的RAM。