PostgreSQL 12查询未命中索引问题排查（Aurora PG场景）

核心原因判断 #

这个查询执行计划的差异主要是PostgreSQL版本优化逻辑差异+统计信息过时共同导致的，和Aurora特性关联不大：

1. PG13对OR条件的索引扫描优化增强
   PostgreSQL 13的查询优化器对OR条件的多索引扫描支持更智能，尤其是对BitmapOr的成本估算更精准。PG12的优化器在处理800万行的大表时，错误认为全表扫描的成本低于两次索引扫描+Bitmap合并的成本，从而选择了全表扫描；而PG13的小表（20万行）本身索引扫描成本占比更低，优化器自然选择更高效的索引路径。

2. PG12的autovacuum机制缺陷导致统计信息过时
   你提到的PG13更新日志内容翻译后为：

允许插入操作（而不仅仅是更新和删除）触发自动清理（autovacuum）活动（Laurenz Albe, Darafei Praliaskouski）

在PG12及更早版本中，只有更新、删除操作会触发autovacuum收集统计信息。你的PG12表有800万行且几乎只有插入操作，导致统计信息严重过时——从执行计划能看到，优化器估算匹配行数为37344，但实际匹配0行，错误的估算直接导致了糟糕的执行计划选择。

验证与解决步骤 #

1. 手动更新统计信息（紧急缓解） #

在PG12实例上执行以下命令，强制更新表的统计信息：

ANALYZE table1;

执行后重新运行目标查询，通常优化器会基于准确的统计信息选择索引扫描路径。

2. 调整表级autovacuum参数（长期修复） #

针对PG12的table1，修改autovacuum参数让插入操作也能触发统计信息更新：

-- 设置插入行数阈值：当插入超过1000行时触发autovacuum
ALTER TABLE table1 SET (autovacuum_vacuum_insert_threshold = 1000);
-- 设置插入比例阈值：当插入行数占表总量1%时触发autovacuum
ALTER TABLE table1 SET (autovacuum_vacuum_insert_scale_factor = 0.01);

这两个参数组合可以确保大量插入后，统计信息能及时更新，避免优化器基于过时数据做决策。

3. 强制使用索引（临时 workaround） #

如果手动ANALYZE后优化器仍未选择索引，可以用索引提示强制指定索引：

SELECT * FROM table1
WHERE col2 = '\x3be8f76fd6199cbbcd4134bf505266841579817de7f3e59fe3947db6b5279fe2' 
   OR col1 = 'ORrKzFeI37dV-bnk1heGopi61koa9fmO'
LIMIT 1
USING INDEX idx_col2, idx_col1;

注意：索引提示仅作为临时解决方案，优先通过更新统计信息让优化器自主选择最优路径。

本地无法复现的原因 #

本地测试场景通常不具备生产环境的条件：

• 数据量远小于生产的800万行，小表的索引扫描成本远低于全表扫描，优化器会直接选择索引；
• 本地测试时的插入操作可能触发了autovacuum（比如测试时频繁插入删除），统计信息始终保持最新，优化器能做出正确决策。

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