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

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

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

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

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

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

存在一些性能问题，如索引碎片。但这些都是很容易解决的(梳子guids由吉米尼尔森:http://www.informit.com/articles/article.aspx?p=25862)

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

@Matt Sheppard我想他的意思是你可以用不同的guid作为主键来复制行。这是任何类型的代理键都存在的问题，而不仅仅是guid。就像他说的，这很容易解决，只需向非键列添加有意义的惟一约束。另一种选择是使用天然钥匙，而这些钥匙存在实际问题。

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

到目前为止还没有提到的一件事是:uuid使分析数据变得更加困难

至少对于web应用程序来说，通过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的非连续性质缓解了这些问题。这并不是为了防止侧写，但这是一个开始。

优点:

UUID值在表和数据库之间是唯一的。这就是为什么它可以合并两个数据库或分布式数据库之间的行。 UUID在url中传递比整型数据更安全。 如果一个UUID通过url传递，攻击者无法猜测下一个id。但是如果我们传递Integer类型，例如10，那么攻击者可以猜测下一个id是11，然后是12等等。 UUID可以离线生成。