这可能是一个非常幼稚和愚蠢的问题，但无论如何我都会问它
我有一个包含多个字段的表，其中没有一个是唯一的，还有一个主键，显然是。
此表通过非唯一字段定期访问，但没有用户SP或进程通过主键访问数据。那么主键是必要的吗？它是在幕后使用的吗？删除它会影响性能的正面还是负面？
答案 0 :(得分：42)
必要吗？没有在幕后使用？好吧，它被保存到磁盘并保存在行缓存等中。删除会稍微提高你的性能（使用精确到毫秒精度的手表）。
但是...下次有人需要创建对此表的引用时，他们会诅咒你。如果他们勇敢，他们将添加PK（并等待DB创建列的时间很长）。如果他们不勇敢或愚蠢，他们将开始使用业务密钥（即数据列）创建引用，这将导致维护噩梦。
结论：由于PK的成本（即使它没有使用ATM）是如此之小，所以就这样吧。
答案 1 :(得分：13)
你有外国钥匙，你有没有加入PK？
如果答案是否定的，并且您的应用程序从不通过其PK从表中检索项目，并且没有查询曾在where子句中使用它，那么您只需添加IDENTITY列以获得PK，然后：
如果你有NC索引，那么你有一个狭窄的人工聚类密钥（IDENTITY PK）的事实有助于保持这些索引变窄（CDX密钥在每个NC叶子槽中再现）。因此，如果您有大量的NC索引，即使从未使用PK，也会有所帮助。
另一方面，如果你有一个流行的访问模式，某个超过所有其他查询的查询是频率和重要性，或者是关键时间代码路径的一部分（例如，每次访问页面时运行查询）在您的网站上，或每秒和应用程序等）然后该查询是一个很好的候选人来决定群集密钥顺序。
最后，如果该表很少被查询但经常被写入，那么它可能是HEAP的良好候选者（根本没有集群密钥），因为堆在插入方面要好得多。请参阅Comparing Tables Organized with Clustered Indexes versus Heaps。
答案 2 :(得分：5)
主键是幕后的clustered index（默认情况下除非作为非聚集索引生成）并保存表的所有数据。如果PK是标识列，则插入将按顺序发生，并且不会发生页面拆分。
但是如果你根本不访问id列，那么你可能想在其他列上添加一些索引。此外，当您拥有PK时，您可以设置FK关系
答案 3 :(得分：4)
在逻辑模型中，表必须至少有一个键。没有理由任意指定其中一个键是'主键';所有键都相等。尽管“主键”的概念可以追溯到特德·科德的早期作品，但早期的错误在关系理论中早已得到纠正。
可悲的是，PRIMARY KEY发现它已进入SQL，从此我们不得不忍受它。 SQL表可以有重复的行，如果您认为SELECT查询的结果集也是一个表，那么SQL表也可以有重复的行。关系理论家不喜欢SQL。但是，仅仅因为SQL允许你做各种古怪的非关系事物，这并不意味着你必须真正做到这一点。确保每个SQL表至少有一个密钥是好的做法。
在SQL中，单独使用PRIMARY KEY会产生影响，例如NOT NULL，UNIQUE，表的外键默认参考。在SQL Server中，单独使用PRIMARY KEY会产生影响，例如表的聚集索引。但是，在所有这些情况下，可以使用特定语法使隐式行为显式化。
您可以组合使用UNIQUE（约束而不是索引）和NOT NULL来强制执行SQL中的键。因此，不，SQL Server中不需要主键（甚至PRIMARY KEY）。
答案 4 :(得分：3)
我永远不会有没有主键的表。假设您需要删除重复项 - 您将如何识别要删除哪个副本以及要保留哪个副本？
答案 5 :(得分：1)
定义时的主键有助于提高数据库中的索引和关系性能。
我总是倾向于在我的所有表中将主键定义为自动递增整数，无论我是否访问它，这是因为当您开始扩展应用程序时，您可能会发现实际上需要它，它让生活变得更加简单。
答案 6 :(得分：1)
不需要PK。
但是您应该考虑在用于查询的列上放置一个非唯一索引（即出现在WHERE子句中的列）。这将大大提高查找性能。
答案 7 :(得分：1)
主键实际上是域模型的属性，它唯一地标识域对象的实例。
在单个增加的列（例如标识列）上具有聚簇索引将意味着不会发生页面拆分，但是插入将使索引随时间失衡，因此重建索引需要定期完成（或者当碎片到达时某个门槛）。
我必须有一个很好的理由来创建一个没有主键的表。
答案 8 :(得分：0)
如果您通过非关键字段访问它们，性能可能不会改变。但是，保留PK以用于将来对这些表的增强或接口可能会很好。您的应用程序只使用这一个表吗？
答案 9 :(得分：0)
正如SQLMenace所说，聚簇索引是表的物理布局的重要列。另外，拥有一个聚簇索引，特别是像瘦整数pk那样精心选择的聚簇索引，实际上会提高插入性能。