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

@Matt谢泼德:

假设你有一桌子的顾客。当然，您不希望一个客户在表中存在多次，否则整个销售和物流部门将会发生许多混乱(特别是当关于客户的多行包含不同的信息时)。

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

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

Some "architect" might tell you that "oh, but we handle the real customer uniqueness constraint in our app tier!". Right. Fashion regarding that general purpose programming languages and (especially) middle tier frameworks changes all the time, and will generally never out-live your database. And there is a very good chance that you will at some point need to access the database without going through the present application. == Trouble. (But fortunately, you and the "architect" are long gone, so you will not be there to clean up the mess.) In other words: Do maintain obvious constraints in the database (and in other tiers, as well, if you have the time).

换句话说:向表中添加GUID列可能有很好的理由，但请不要因此降低了在真实(==非GUID)信息中保持一致性的目标。

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

如果您还将该列用作聚集索引(一种相对常见的做法)，那么使用GUIDS作为主键需要考虑的另一个小问题是。你会在插入时受到打击，因为guid的本质不是按顺序开始的，因此当你插入时，它们会出现页面分割等。只是需要考虑的问题，如果系统将有高IO…

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

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

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

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