2

这是一种一般的数据库设计问题。如果有一个关联实体表，即交叉引用，包含基本上只包含两个 FK 引用的记录，是否应该以某种方式对其进行索引？是否有必要显式索引该表，因为关联表中的 PK 已经按定义进行了索引？如果应该索引它，它应该是一个组合索引，由两个 FK 字段组成吗？

4

2 回答 2

3

其他表中引用的 pk 列上的索引不包括它。

通过将两个 fk 列定义为“关联实体”表的复合主键（在大多数情况下您应该这样做 - 假设关联是唯一的），您可以隐式创建多列索引。

这以最佳方式涵盖了涉及两列或第一列的所有查询。
它还涵盖了对第二列的查询，但以一种不太有效的方式。
如果您有仅涉及第二列的重要查询，请在该列上创建一个附加索引。

在 dba.SE上的这个相关问题中阅读有关该主题的所有详细信息。
或者这个关于 SO的问题，也涵盖了这个话题。

于 2012-04-26T15:11:58.587 回答
1

假设您的关联表具有如下模式：

CREATE TABLE Association
(
    ReferenceA  INTEGER NOT NULL REFERENCES TableA CONSTRAINT FK1_Association,
    ReferenceB  INTEGER NOT NULL REFERENCES TableB CONSTRAINT FK2_Association,
    PRIMARY KEY(ReferenceA, ReferenceB)            CONSTRAINT PK_Association
);

您的 DBMS 可能会自动创建一些索引。

一些 DBMS 将为两个外键中的每一个创建一个索引，并为主键创建一个唯一索引。这有点浪费，因为 PK 索引也可以用于访问 ReferenceA。

理想情况下，将只有两个索引：PK（唯一）索引和 ReferenceB 的（允许重复的）FK 索引，假设 PK 索引将 ReferenceA 作为第一列。

如果 DBMS 没有自动创建索引来强制执行参照完整性约束，则您需要创建 RI 或 FK 允许重复索引。如果它没有自动创建索引来强制执行 PK 约束，那么您也需要创建该唯一索引。好处是您只会为理想情况创建索引。

根据您的 DBMS，您可能会发现创建没有约束的表，然后添加索引，然后添加约束（然后将使用您创建的索引）更有效。像碎片化方案这样的事情也可能会影响到这一点；我在上面忽略了它们。

这个概念仍然很简单——您总共需要两个索引，一个在两列上强制唯一性并提供对前导列的快速访问，以及一个在尾随列上的非唯一或允许重复的索引。

于 2012-04-26T15:58:50.307 回答