Rails+PostgreSQL下BProducts表category_id查询未走索引的优化问题

碰到这种情况我太熟悉了——明明两个表结构、索引配置都一致，查询同一个category_id，一个秒出结果用索引，另一个却慢到离谱走全表扫描。咱们从PostgreSQL查询优化器的逻辑入手，一步步找原因和解决办法：

可能的核心原因 #

PostgreSQL的查询优化器会根据统计信息判断用索引还是全表扫描更快，出现这种差异大概率是统计信息或者索引本身的问题：

1. 统计信息过时/不准确
   优化器看到BProduct的category_id=700预估只有926条，但如果实际数据分布和统计信息不符（比如统计信息很久没更新，或者数据批量导入后没做分析），它可能错误地认为全表扫描比索引扫描成本更低。对比AProduct的预估行数1359，优化器却选择了索引，说明A的统计信息是准确的。

2. 索引本身异常
   虽然你说category_id有索引，但可能索引已经损坏、无效，或者创建时出了问题（比如建索引过程中被中断）。

3. 表碎片化严重
   如果BProduct经历过大量的删除、更新操作，表和索引的碎片化会导致索引扫描的成本被优化器高估，进而选择全表扫描。

一步步解决办法 #

1. 先确认索引是否真的存在且有效 #

先在PostgreSQL控制台执行这条SQL，检查BProduct的category_id索引状态：

-- 检查索引是否存在
SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'b_products' AND indexdef LIKE '%category_id%';

-- 检查索引是否有效
SELECT idx.indexrelid::regclass AS index_name, idx.indisvalid 
FROM pg_index idx 
JOIN pg_class tbl ON idx.indrelid = tbl.oid 
WHERE tbl.relname = 'b_products' 
AND idx.indexrelid::regclass::text LIKE '%category_id%';

如果indisvalid显示f，说明索引无效，需要重建索引：

REINDEX INDEX index_b_products_on_category_id;

2. 更新统计信息（最可能解决问题） #

PostgreSQL的ANALYZE命令会更新表的统计信息，让优化器能做出正确的选择：

ANALYZE b_products;

执行完之后再跑一次BProduct.where(:category_id => 700).explain，看看是不是换成索引扫描了。

3. 处理表碎片化 #

如果更新统计信息还是没效果，可能是表碎片化问题，执行VACUUM ANALYZE清理碎片并更新统计：

VACUUM ANALYZE b_products;

如果碎片特别严重，也可以考虑重建表（但需要锁表，建议低峰期操作）：

ALTER TABLE b_products REPLICA IDENTITY FULL;
CREATE TABLE b_products_new AS TABLE b_products;
DROP TABLE b_products;
ALTER TABLE b_products_new RENAME TO b_products;
-- 重建索引
CREATE INDEX index_b_products_on_category_id ON b_products (category_id);

4. 临时强制使用索引（最后手段） #

如果以上方法都不行，可以在Rails里强制指定使用索引，验证索引是否能正常工作：

BProduct.where(:category_id => 700).force_index(:index_b_products_on_category_id).explain

如果强制后查询速度变快，说明还是统计信息的问题，再仔细检查统计信息的更新情况。

总结 #

大部分情况下，更新统计信息（ANALYZE）就能解决这个问题，因为PostgreSQL优化器完全依赖统计信息做决策。如果是索引损坏或者碎片化问题，重建索引或清理碎片就能恢复正常。

内容的提问来源于stack exchange，提问作者D-Nice