PostgreSQL-具有相同列的多个索引

Question

假设我

• 有一个包含a ， b ， c和d列的表
• 希望结合这些列的SELECT查询能够快速发展
• 想到要在每个查询
• 不在乎慢的UPDATE和INSERT

我应该创建哪些索引，并且以不同的顺序创建具有相同列的多个索引是一个可怕的想法？

（a，b）

（a，c）

（a，b，c）

（a，c，b）

...

（A B C D）

（a，d，c，b）

...

Answer 1

从理论上讲，如果您完全不关心更新/插入速度和过多的索引大小（磁盘空间），那么您将需要查询的WHERE子句中使用的所有可能的列组合，并且查询计划者将决定使用哪个列。 但是索引是否完全有用取决于表数据。

索引列的顺序起着非常重要的作用。 列应按基数排序。 让我们看一个例子：

我们有一个人的表（id，姓，名，year_of_birth，性别）。 什么索引适合这里？

1. 按名称过滤

我们应该添加哪个索引-（姓，名）或（名字，姓）？ 正确的答案是（姓，名），因为如果按姓对记录进行分组，则肯定会有更多的记录。

2. 按姓名和出生年份过滤

假设我们已经有了（姓，名）索引。 我们应该将其更改为（姓，名，年）吗？ 可能会有一些好处，但是我对此表示怀疑。 对于任何给定的姓和名，可能只有几条不同年龄的记录。 关键是，如果我们拥有几乎唯一的组合（例如姓氏+名字），那么向索引添加更多列将无济于事。

3. 按性别过滤

不需要索引。 因为只有两个可能的值：男性/女性。 因此索引将不会有效。

---

除了这些索引很棒而且必不可少之外，我还要注意以下几点：

• 索引占用额外的磁盘空间
• 索引影响更新/插入速度
• 并非所有索引都是有效的（对于一小部分记录，顺序扫描会更快，因为索引查找并不是自由的性能）
• 最终，要使用哪个索引由查询计划者决定，并且取决于很多因素。 有时，即使您有索引，它也可能更喜欢顺序扫描。 因此，直到进行测试，您才知道。

---

文档的一个好处： 合并多个索引

在除最简单的应用程序之外的所有应用程序中，都有各种可能有用的索引组合，并且数据库开发人员必须权衡取舍才能确定要提供的索引。 有时多列索引是最好的，但是有时最好创建单独的索引并依靠索引组合功能。

Answer 2

这个问题目前无法解决。 影响索引选择和有用性的因素包括：

• 列中数据的基数
• 表中数据的大小
• 数据类型
• 指数的新鲜度
• 查询调整参数
• 是的，索引中列的顺序

这一切都这样说，只有这样，才能知道你的指标将如何执行，是有代表性的数据来进行测试。 抱歉，这里没有捷径。