Postgresql 中主键与外键的自动索引创建

Question

对于 PostgreSQL 9.4 ( http://www.postgresql.org/docs/9.4/static/ddl-constraints.html ) 指出

外键必须引用作为主键或形成唯一约束的列。这意味着被引用的列总是有一个索引（主键或唯一约束的基础）；因此检查引用行是否匹配将是有效的。由于从被引用表中删除一行或对被引用列进行更新将需要扫描引用表以查找与旧值匹配的行，因此索引引用列通常也是一个好主意。因为这并不总是需要，而且有很多关于如何索引的选择，外键约束的声明不会自动在引用列上创建索引。

我想知道这些行的作者是否忽略了一个主要观点：当我有一个父子关系（例如带有购物车位置的购物车）时，孩子（购物车位置）标记其与父项（购物车）的关系当我想获取给定父级的所有子级时，使用父级（购物车）主键的外键我使用非索引外键列。

因此，默认情况下不为外键列生成索引（与主键列相反）和让用户体验次优性能的开销是否超过维护索引的开销，而维护索引在较小的表大小下仅执行另一方面，查询性能的微小改进？

也许有人对导致此决定的数据库实现细节和推理有更多见解和/或可以指出为什么外键列的默认索引生成（在 Postgresql 中）可能导致未被注意的严重问题的原因。

Answer 1

我不认为 - 外键列的默认索引生成 - 会导致严重的问题。

这只是 PostgreSQL 开发人员做出的决定，将这个选择留给每个数据库设计人员/管理员。我们可以选择在创建外键时是否添加索引。

如果他们做出相反的决定，那么我们就会受到限制。每个外键约束都会有一个索引。如果有人想要一些未编入索引的外键列，它们将受到限制或强制。

现在，对于那些想要添加索引以匹配外键约束的人来说，只有额外的负担。

就个人而言，我几乎总是为外键约束添加相应的索引。但通常，索引与约束不完全匹配。例如，Fk 可能是TABLE c (..., FOREIGN KEY (a_id) REFERENCES a (a_id) )，索引可能是单个(a_id)或复合的，(a_id, b_id)因为它也有助于其他查询，而不仅仅是那些使用a_id.

或者我可能有（更罕见的情况）2 个可以覆盖的外键约束，但只有 1 个索引 - 例如：FK (a_id) REFERENCES a (a_id), ... FK (a_id, b_id) REFERENCES b (a_id, b_id).

创建索引时，也有很多选项，比如索引的类型（btree, hash, Gin, Gist 和其他外来类型），所以我们可以自由选择最适合我们情况的。

另请注意，Oracle、SQL Server、DB2 和 Firebird 也不会自动为FOREIGN KEY列创建索引，因此并非只有 PostgreSQL 开发人员会这样做。而且我确定对此事进行了很多讨论，他们考虑了两种选择，我只是在推测他们做出决定的原因。查看旧的 Postgres 讨论列表可能会揭示更多有关他们考虑的实际原因的信息。