由多个键组成的复合键是否会影响性能？

Question

我有一种情况，复合键由 5 个或更多键组成，如下所示。

选项1：

Test table:
schoolid
testid  --composite Primary key on both the columns

TestStudent table:
schoolId
testId
studentId  -- composite primary key of all columns

TestStudentMCQ table:
schoolid
testid
studentid
choiceid  --composite Primary key of all columns

我可以制作Test桌子的PK，TestId这样MCQAnswer桌子就会有TestId, StudentId, QuestionId and ChoiceId

如果性能影响不大，我更愿意选择第一个选项。

此外，我将 RLS 与SchoolId.

我还想在这里提一下：

我还有另一个表 TestStudent，它具有如上所示的复合主键。同样的事情可以设计如下。

选项 2：

Test table:
schoolid
testid  --composite Primary key on both the columns

TestStudent table:
id
schoolId
testId
studentId  -- id is the identity primary key here

TestStudentMCQ table:
testStudentId
choiceid  --composite Primary key of both columns

哪种方法更好？

Answer 1

指定主键起源于 ISAM 和其他数据库类型的前关系时代，不幸的是，Codd、Date 等人将其纳入关系术语作为逻辑设计的一部分。我说不幸的是，因为大型关系供应商然后将它重新纳入物理设计作为性能最佳外键查找机制的规范- 物理设计属性。

由于这种混淆，我尽可能避免使用术语主键。逻辑设计中有自然（或业务）键，物理设计中有代理键。是否在特定表上使用代理键的决定是一个棘手的问题，但可以说一件事：如果已知一个表的行数永远不会超过 50 到 200 行，那么引擎可能永远不会使用索引查找，因此不需要代理键。毋庸置疑，出于逻辑和物理设计的原因，所有键，无论是自然键还是代理键都应该由唯一索引强制执行。

但是，作为关系表的原则，也就是说处于第一范式，每个表都有一个自然（或业务）键。由于代理键永远不应该暴露给用户，这样的自然业务键成为用户指定单个行的唯一方法。

当人们选择实现代理键时，用于强制执行该键的索引几乎总是最好的聚集索引。

解决您的具体问题：是的，大型复合键上的聚集索引肯定会影响包含超过 100 或 200 行的表的性能。使用非聚集索引强制执行您的（复合）自然键，并可能向该索引添加一些精心挑选的附加覆盖字段。除非您有非常好的和有据可查的理由，否则将强制执行您的代理键的索引设为聚集索引。

原因是：

• 索引高度与键宽度成反比。宽复合索引可以比窄索引少一两个（或更多！）级别，需要更多的软和硬页面错误以及更多的缓存使用，这不仅会影响表本身的查找性能，还会影响由该表提供服务的所有内容的性能引擎。

• 通过非聚集索引的每次查找，除非被该索引覆盖，否则需要通过聚集索引键进一步查找聚集索引。使聚集索引查找高效非常重要，因为它们控制所有查找的效率。

最后，请记住记录所有集群和索引决策及其在逻辑和物理设计中的影响和基本原理。DBA 将定期审查物理设计决策，以了解调优性能的方法和方法，但决不能出于性能原因更改严格在逻辑设计中做出的决策。帮助您的 DBA 并清楚地标记哪些是哪些。