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

RDBMs通常确保主键的唯一性，并确保在一种名为BTree的结构中按键进行查找，这是一种具有较大分支因子的搜索树(二叉搜索树的分支因子为2)。现在，一个连续整数ID将导致插入只发生在树的一侧，而大多数叶节点不受影响。添加随机uuid将导致插入拆分整个索引中的叶节点。

同样地，如果存储的数据主要是临时的，通常情况下需要访问最新的数据，并根据最新的数据进行连接。对于随机uuid，模式将无法从中受益，并将访问更多的索引行，因此需要内存中更多的索引页。如果最需要最近的数据，那么使用顺序id，热索引页将需要更少的RAM。

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

RDBMs通常确保主键的唯一性，并确保在一种名为BTree的结构中按键进行查找，这是一种具有较大分支因子的搜索树(二叉搜索树的分支因子为2)。现在，一个连续整数ID将导致插入只发生在树的一侧，而大多数叶节点不受影响。添加随机uuid将导致插入拆分整个索引中的叶节点。

同样地，如果存储的数据主要是临时的，通常情况下需要访问最新的数据，并根据最新的数据进行连接。对于随机uuid，模式将无法从中受益，并将访问更多的索引行，因此需要内存中更多的索引页。如果最需要最近的数据，那么使用顺序id，热索引页将需要更少的RAM。

优点:

可以离线生成。 使复制变得简单(与int's相反，这使得它非常困难) ORM通常是这样的 跨应用程序惟一。所以我们可以在我们的应用程序(也guid)中使用CMS (guid)中的PK，并且知道我们永远不会发生冲突。

缺点:

更大的空间使用，但空间是便宜的 无法按ID排序以获取插入顺序。 可以在URL中看起来很丑，但真的，WTF是你在URL中放一个真实的DB键!?(这一点在下面的评论中有争议) 手动调试比较难，但也没那么难。

就我个人而言，我在任何一个相当大的系统中使用它们进行大多数PK，但我在一个到处都被复制的系统上接受了“训练”，所以我们必须使用它们。YMMV。

我认为重复数据的事情是垃圾-你可以得到重复的数据，无论你做什么。在我工作的任何地方，代理键通常都不受欢迎。我们确实使用类似于wordpress的系统:

行的唯一ID (GUID/其他)。用户永远不可见。 public ID从某些字段生成一次(例如title-让它成为the-title-of- article)

更新: 所以这一个得到了很多+1，我想我应该指出GUID PK的一个大缺点:聚集索引。

如果您有很多记录，并且在GUID上有一个聚集索引，那么您的插入性能将非常糟糕，因为您将插入到项目列表中的随机位置(这是重点)，而不是在末尾(这是快速的)。

因此，如果你需要插入性能，也许可以使用auto-inc INT，如果你想与其他人共享它，则生成一个GUID(例如，在URL中向用户显示它)。

primary-keys-ids-versus-guids

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

神话，GUID vs. Autoincrement (MySQL 5)

这就是你真正想要的。

UUID优点

每个表，每个数据库，每个服务器都是独一无二的 允许轻松合并来自不同数据库的记录 允许跨多个服务器轻松分布数据库 您可以在任何地方生成id，而不必往返于数据库 大多数复制场景都需要GUID列

GUID笨蛋

它比传统的4字节索引值大了4倍;如果不小心，这可能会对性能和存储造成严重影响 调试很麻烦(其中userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}') 生成的guid应该是部分顺序的，以获得最佳性能(例如，SQL 2005上的newsequentialid())，并允许使用聚集索引

guid在将来可能会给您带来很多麻烦，如果它们被用作“唯一符”，让重复的数据进入您的表。如果您想使用guid，请考虑在其他列上仍然保持unique -约束。

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