PostgreSQL未使用intarray索引而执行全表扫描问题排查

结合你的场景（50万行表、integer[]列、gin__int_ops索引、<@包含查询），我来拆解几个最可能的原因，都是日常排查这类问题时踩过的坑：

1. 统计信息过时，PostgreSQL判断错了成本 #

你的执行计划里预估只返回11行，但PostgreSQL还是选了全表扫描，大概率是表的统计信息没跟上数据变化。PostgreSQL完全依赖统计信息来判断“走索引划算还是全表扫划算”，如果统计信息过时，它可能错误认为这个查询返回的行数远多于实际，或者索引的IO成本被高估了。

解决办法很简单，手动更新统计信息：

ANALYZE some_tbl;

更新完再跑一遍查询，看看执行计划会不会切换到索引扫描。

2. 操作符和索引的操作符类不匹配 #

你用的是intarray扩展的gin__int_ops操作符类，但要注意：PostgreSQL里默认的数组<@操作符和intarray扩展的<@操作符是重载的不同操作符！

如果你的查询默认调用的是系统自带的数组操作符，而不是intarray扩展的，那GIN索引根本不会被触发。你可以先查一下当前<@操作符的归属：

SELECT oprname, oprnamespace::regnamespace 
FROM pg_operator 
WHERE oprname = '<@' AND oprleft = 'integer[]'::regtype;

如果结果里有多个条目，说明存在操作符重载。这时候你可以在查询里显式指定intarray的操作符类来强制走索引：

SELECT count(*) 
FROM some_tbl 
WHERE agg_series_id <@ ARRAY[1]::integer[] USING gin__int_ops;

3. PostgreSQL真觉得全表扫描更划算 #

虽然执行计划预估返回11行，但PostgreSQL的成本计算模型可能认为：读取GIN索引再回表的总成本，比直接扫一遍全表更高。比如你的表数据在磁盘上是连续存储的，全表扫的IO效率极高；或者索引本身太大，回表的随机IO成本超过了全表扫的顺序IO成本。

你可以临时禁用全表扫描来验证这个猜想：

-- 临时关闭全表扫描开关
SET enable_seqscan = off;
SELECT count(*) FROM some_tbl WHERE agg_series_id <@ ARRAY[1];
-- 记得用完改回来，别影响其他查询
SET enable_seqscan = on;

如果禁用后确实走了索引，说明是成本计算的问题。如果你的数据库用的是SSD，可以把random_page_cost参数从默认的4调低到1.1左右，让PostgreSQL更倾向于选择索引扫描。

4. 索引本身有问题 #

比如索引没建成功、或者因为某种原因损坏了。你可以先查一下索引的使用情况：

SELECT indexrelname, idx_scan 
FROM pg_stat_user_indexes 
WHERE relname = 'some_tbl';

如果idx_scan一直是0，说明这个索引从来没被用过。这时候可以尝试重建索引：

REINDEX INDEX idx_agg_series_id;

内容的提问来源于stack exchange，提问作者Gruender