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 回答