是SQL Server中必需的主键吗？

Question

这可能是一个非常天真和愚蠢的问题，但无论如何我都会问它

我有一个包含多个字段的表，其中没有一个是唯一的，还有一个主键，显然是。

此表通过非唯一字段定期访问，但没有用户SP或进程通过主键访问数据。 那么主键是必要的吗？ 它是在幕后使用的吗？ 删除它会影响性能的正面还是负面？

Answer 1

必要？ 没有在幕后使用？ 好吧，它保存到磁盘并保存在行缓存等中。删除会略微提高性能（使用精度为毫秒精度的手表）。

但是......下次有人需要创建对此表的引用时，他们会诅咒你。 如果他们勇敢，他们将添加PK（并等待DB创建列的时间很长）。 如果他们不勇敢或愚蠢，他们将开始使用业务键（即数据列）创建引用，这将导致维护噩梦。

结论：由于PK的成本（即使它没有使用ATM）是如此之小，所以就这样吧。

Answer 2

你有外国钥匙，你有没有加入PK？

如果答案是否定的，并且您的应用程序永远不会通过其PK从表中检索项目，并且没有查询在where子句中使用它，那么您只需添加IDENTITY列以获得PK，然后：

• PK本身没有增加任何价值，但也没有任何损害
• 事实上PK很可能也是聚集索引.. 这取决于 。

如果你有NC索引，那么你有一个狭窄的人工聚类密钥（IDENTITY PK）的事实有助于保持这些索引变窄（CDX密钥在每个NC叶子槽中再现）。 因此，如果您有重要的NC索引，即使从未使用PK，也会有所帮助。

另一方面，如果您有一个流行的访问模式，某个超过所有其他查询的查询是频率和重要性，或者是关键时间代码路径的一部分（例如，在您网站上每次访问页面时运行查询）或者每秒和app等）然后该查询是指示聚簇键顺序的良好候选者。

最后，如果表很少被查询但经常被写入，那么它可能是HEAP的良好候选者（根本没有集群密钥），因为堆在插入方面要好得多。 请参阅比较使用群集索引与堆组织的表 。

Answer 3

主键是幕后clustered index （默认情况下除非生成为非聚簇索引）并保存表的所有数据。 如果PK是标识列，则插入将按顺序发生，并且不会发生页面拆分。

但是如果你根本不访问id列，那么你可能想在其他列上添加一些索引。 此外，当您有PK时，您可以设置FK关系

Answer 4

在逻辑模型中，表必须至少有一个键。 没有理由任意指定其中一个键是'主键'; 所有键都相等。 尽管“主键”的概念可以追溯到特德·科德的早期作品，但早期的错误在关系理论中早已得到纠正。

可悲的是， PRIMARY KEY发现它已经进入SQL，我们不得不忍受它。 SQL表可以有重复的行，如果您认为SELECT查询的结果集也是一个表，那么SQL表也可以有重复的行。 关系理论家不喜欢SQL。 但是，仅仅因为SQL允许你做各种古怪的非关系事物，这并不意味着你必须真正做到这一点。 确保每个SQL表至少有一个密钥是一种好的做法。

在SQL中， PRIMARY KEY使用PRIMARY KEY会产生影响，例如NOT NULL ， UNIQUE ，表的外键默认引用。 在SQL Server中， PRIMARY KEY使用PRIMARY KEY会产生影响，例如表的聚簇索引。 但是，在所有这些情况下，可以使用特定语法使隐式行为显式化。

您可以组合使用UNIQUE （约束而不是索引）和NOT NULL来强制SQL中的键。 因此，不，SQL Server中不需要主键（甚至PRIMARY KEY ）。

Answer 5

我永远不会有没有主键的表。 假设您需要删除重复项 - 您将如何识别要删除哪个副本以及要保留哪个副本？

Answer 6

定义时的主键有助于提高数据库内的索引和关系性能。

我总是倾向于在我的所有表中将主键定义为自动递增整数，无论​​我是否访问它，这是因为当您开始扩展应用程序时，您可能会发现实际上需要它，并且它让生活变得更简单。

Answer 7

PK不是必需的。

但是您应该考虑在用于查询的列上放置一个非唯一索引（即出现在WHERE子句中）。 这将大大提高查找性能。

Answer 8

主键实际上是域模型的属性，它唯一地标识域对象的实例。

在单个增加的列（例如标识列）上具有聚簇索引将意味着不会发生页面拆分，但是插入将使索引随时间失衡，因此重建索引需要定期完成（或者当碎片达到某个阈值时） 。

我必须有一个很好的理由来创建一个没有主键的表。

Answer 9

如果您通过非关键字段访问它们，性能可能不会改变。 但是，保留PK以用于将来对这些表的增强或接口可能会很好。 您的应用程序仅使用此表吗？

Answer 10

正如SQLMenace所说，聚簇索引是表的物理布局的重要列。 另外，拥有聚簇索引，特别是像瘦整数pk那样精心选择的聚簇索引，实际上会提高插入性能。