在 Postgresql 中有重复索引有什么害处吗？

【问题标题】：Is there any harm to having a duplicate index in Postgresql?在 Postgresql 中有重复索引有什么害处吗？
【发布时间】：2012-03-21 09:23:24
【问题描述】：

我有以下结构。

CREATE TABLE join_table (
  id integer NOT NULL,
  col_a integer NOT NULL,
  col_b integer NOT NULL
)

CREATE INDEX index_on_col_a ON join_table USING btree (col_a);
CREATE INDEX index_on_col_b ON join_table USING btree (col_b);
CREATE UNIQUE INDEX index_on_col_a_and_col_b ON join_table USING btree (col_a, col_b);

col_a 和 col_b 上也有外键。

显然 index_on_col_a 不再需要，但是保留或删除它是否有成本或收益？

我的猜测是；

保留它会减慢插入速度
如果我保留它，仅使用 col_a 进行选择可能会更快

【问题讨论】：

好像你已经知道答案了？
嗯...我应该避免猜测问题吗？也许有人比猜测更有把握。
视情况而定，写性能好还是查询性能好，但我个人认为需要drop index index_on_col_a
感谢@francs。我通常会。我只是想验证一下我是对的。我想我会删除它。
我们已经讨论过这个案例in great detail at dba.SE recently。

标签： sql postgresql indexing postgresql-9.1

【解决方案1】：

您可以删除col_a 上的索引。如果您在col_a 上查询，PostgreSQL 可以使用组合索引，如果您在col_a 和col_b 上查询，也可以使用该索引。这些查询类型可以使用组合索引：

WHERE col_a = 'val'
WHERE col_a = 'val' AND col_b = 'val'

组合索引不能仅用于查询col_b 或col_a 和col_b 的OR 联结。因此，如果您经常有查询仅查询 col_b，则在 col_b 之上的附加索引可能有意义。

编辑：所以：创建index_on_col_a 没有优势，但写入速度较慢。放下它。

【讨论】：