这是一个通用的数据库设计问题。如果有一个关联实体表，即交叉引用，包含基本上只包含两个 FK 引用的记录，是否应该以某种方式对其进行索引？是否有必要显式索引该表，因为关联表中的 PK 已经按定义进行了索引？如果要索引，是否应该是组合索引，由两个FK字段组成？
【问题讨论】：
标签： postgresql database-design
其他表中引用的 pk 列上的索引不包括它。
通过将两个 fk 列定义为“关联实体”表的复合主键（在大多数情况下您应该这样做 - 前提是关联是唯一的），您可以隐式创建多列索引.
最好地涵盖所有涉及两列或第一列的查询。
它还涵盖了第二列上的查询，但效率较低。
如果您有仅涉及第二列的重要查询，也可以在该列上创建一个附加索引。
在related question on dba.SE阅读有关该主题的所有详细信息。
或者this question on SO，也涵盖了这个话题。
【讨论】：
假设您的关联表具有如下架构：
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 索引将 ReferenceA 作为第一列，则只有两个索引：PK（唯一）索引和 ReferenceB（允许重复）FK 索引。
如果 DBMS 没有自动创建索引来强制执行参照完整性约束，您将需要创建 RI 或 FK 允许重复的索引。如果它没有自动创建索引来强制执行 PK 约束，那么您也需要创建该唯一索引。好处是您只会为理想情况创建索引。
根据您的 DBMS，您可能会发现创建没有约束的表，然后添加索引，然后添加约束（然后将使用您创建的索引）更有效。像碎片化方案这样的事情也可能会影响到这一点；我在上面忽略了它们。
这个概念仍然很简单——您总共需要两个索引，一个在两列上强制唯一性并提供对前导列的快速访问，以及一个在尾随列上的非唯一或允许重复的索引。
【讨论】：