关于数据库表的部分键和索引的问题答案

【问题标题】：Question on partial keys and an index on a database table关于数据库表的部分键和索引的问题
【发布时间】：2010-06-26 14:33:44
【问题描述】：

假设我对一个数据库表有两个查询。

查询是根据查询中使用的字段定义的：

Query1：取决于 f1、f2 和 f3

Query2：取决于 f1、f2、f3 和 f4

我记得在某处读到 SQL 查询引擎（在本例中为 mySQL）从索引中最左边的字段开始解析索引树。

如果这是正确的，那么我假设不是像这样在表上定义两个索引：

Index 1 (for Query1) : CREATE INDEX idx_1 {f1, f2, f3}
Index 2 (for Query2) : CREATE INDEX idx_2 {f1, f2, f3, f4}

我可以简单地定义一个索引，其中包含两个查询中使用的键的联合 - 即

我只需要定义这个索引：

(for BOTH Query1) : CREATE INDEX the_idx {f1, f2, f3, f4}

我有两个问题：

【问题讨论】：

这个假设是关于 B-TREE，而不是关于其他类型的索引。 Wikipedia 上有关于 HASH、GIN、GIST、RED-BLACK 等的信息。深入了解您的数据库手册，它有更多关于索引实现的信息。

【解决方案1】：

我的假设正确吗？即我可以简单地定义一个索引（the_idx）而不是前两个吗？

是的。
它称为覆盖索引，您希望根据最有可能使用的查询对列进行排序。 IE：如果 f2 是最常见的列，您会想使用：

CREATE INDEX the_idx {f2, f1, f3, f4}

这种索引行为是否也适用于 PostgreSQL 查询引擎？

索引不是 ANSI 标准；供应商之间的术语如此一致，真是奇迹。

【讨论】：

【解决方案2】：

一般来说，更多的索引将是可用的。但是，您添加到该索引的越多，所需的开销就越多。

最好的办法是尝试一下，并查看执行计划，看看它是否以您期望的方式使用。

根据结果集中返回的实际列，使用较短的索引可能更有利。

【讨论】：

【解决方案3】：

MySQL manual 相当清楚地表明，是的，键的任何“前缀”都可以在任何非散列索引（其中大部分）中搜索。

我找不到任何与 PostgreSQL 类似的文档，但您始终可以创建表然后执行 EXPLAIN（无论如何这不是一个坏主意）。

【讨论】：