数组字段上的 btree 索引实际上有什么作用吗？

Question

在PG中你可以创建一个像这样的表

CREATE TABLE foo (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid (),
  name text NOT NULL,
  things text[] NOT NULL DEFAULT ARRAY[] ::text[]
)

以及相关索引

CREATE INDEX foo_text ON foo USING btree (name, things);

但很难找到有关其作用的信息。我继承了一个像这样的表（数亿行，尽管这个数组几乎总是有 0 或 1 个条目），并且索引确实在 pg_stat_all_indexes 中偶尔命中，所以至少在某些情况下可以发生了，但我也注意到，相对于其他索引，该索引占用了大量空间，并且清理速度要慢得多。 PG 中数组字段的索引有意义吗？btree

如果目标是能够找到things包含所提供的一个或多个值的行，是否有更好的方案？（假设我们此时无法将其正确规范化为它自己的表。）

我们期望查询会命中该索引，如下所示

SELECT id FROM foo
WHERE name = $1
AND $2::text = ANY(things)

SELECT id FROM FOO
WHERE name = $1
AND things @> $2::text[]

Answer 1

数组上的 B 树索引无法加快问题中的查询速度。一定是有人错误地创造了它们。

B 树索引应该只索引name。如果该条件已经大大缩小了结果集的范围，那就足够了。things如果您还需要索引来加速条件，请在该列上创建一个单独的 GIN 索引。

请注意，只有使用运算符的条件@>才能使用索引，第一个查询中的条件things无法建立索引。