将主键作为标识字段是否合适？

Question

我已经阅读了很多关于我们是否应该将主键作为标识列的文章，但我仍然感到困惑。

使列具有标识是有好处的，因为它可以在连接中提供更好的性能并提供数据一致性。但是存在与身份相关的主要缺点，即当INSERT语句失败时，仍然IDENTITY值增加如果事务被回滚，则新的IDENTITY列值不会回滚，因此我们最终会在排序中出现空白。我可以使用GUID（通过使用NEWSEQUENTIALID），但它会降低性能。

Answer 1

差距无关紧要：标识栏是内部的，不适合最终用户使用或识别。

由于16字节宽度，GUID会破坏性能，甚至连续性能。

在对数据建模并计算出您的自然键之后，应选择标识列以尊重物理实现。也就是说，所选择的自然键是逻辑键，但您选择代理键（标识），因为您知道引擎的工作方式。

或者您使用ORM并让客户端尾随数据库狗...

Answer 2

出于所有实际目的，整数是主键的理想选择，自动增量是生成它们的完美方式。只要您的PK没有意义（代理），它就会受到保护，免受您客户的创造性影响，并为其主要目的（确定表中的一行）提供服务。索引是打包的，连接得很快，并且很容易对表进行分区 如果您碰巧需要GUID，那也没关系;但是，首先考虑自动递增整数。

Answer 3

我想说这取决于你的需求。我们只使用Guids作为主键（默认设置为NewID），因为我们开发了一个包含许多Sql Server实例的分布式系统，因此我们必须确保每个Sql Server都生成唯一的主键值。 但是当使用Guid列作为PK时，请确保not to use it as your clustered index（感谢marc_s的链接）

Guid类型的优点：

• 您可以在不同位置创建唯一值，而无需同步

缺点：

• 它是一个大型数据类型（16字节），需要更多空间
• 它创建索引碎片（至少在使用newid（）函数时）

主键不是主键，不依赖于数据类型，因为主键必须是唯一的定义！

我不相信标识列具有更好的连接性能。完全，性能是正确索引的问题。主键是约束而不是索引。

你是否需要一个没有间隙的typ int主键？这通常不是问题。

Answer 4

“是的，KILLS的性能 - 完全。我使用GUID作为PK / CK和99.5％索引碎片的遗留系统每天使用INT IDENTITY - 巨大差异。几乎没有任何索引碎片，性能显着更好。作为SQL Server表上的群集索引的GUID是BAD BAD BAD - period。“

可能是真的，但我认为没有合乎逻辑的推理，这使我得出结论，GUID PER SE也很糟糕。

也许你应该考虑对这些数据使用其他类型的索引。如果您的dbms没有为您提供多种类型的索引之间的选择，那么您可能应该考虑让自己成为更好的dbms。