PolarDB for PostgreSQL只读节点为何常选用Seq Scan而非索引？

为啥会出现这种情况？ #

答案是回放状态和成本模型都可能是诱因：

1. 回放状态的影响
   • 只读节点在WAL回放过程中，B+Tree索引或者LogIndex可能存在短暂的同步滞后，比如索引页还在异步刷新，这时候优化器会认为索引状态不可靠，直接选择全表扫描（Seq Scan）。
   • 共享存储模式下，只读节点的索引元数据偶尔会有一致性延迟，优化器拿不到最新的索引状态，自然不会优先选索引扫描。
2. 成本模型的偏差
   • 只读节点默认沿用主节点的成本计算参数，但两者的硬件负载（比如IO延迟、CPU使用率）可能不一样。比如共享存储的读延迟很低，但优化器还是用默认的random_page_cost=4来判断，算出来的索引扫描成本比全表扫描还高，当然不会选索引。
   • 统计信息滞后也是常见问题：主节点更新了表的统计信息，但还没同步到只读节点，优化器拿着旧的数据分布（比如错误认为表行数很少、字段基数很高），会觉得全表扫描更划算。

怎么让只读节点稳定走索引？ #

调优成本模型参数 #

• 改random_page_cost：如果只读节点用的是低延迟共享存储，把这个值从默认的4降到1.1-1.5之间，让优化器意识到随机读（索引扫描主要依赖这个）的成本远低于顺序读。
• 调cpu_index_tuple_cost：要是只读节点CPU资源充足，把这个参数从默认的0.005调低到0.001左右，降低索引扫描的CPU成本权重，让优化器更倾向于选索引。
• 确认enable_bitmapscan是on：这个参数默认是开启的，但还是要检查下有没有被误改，确保优化器能考虑Bitmap Scan选项。

确保回放与索引状态正常 #

• 查回放延迟：执行SELECT pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();，看两个值的差距是不是很小，要是差得大，说明回放滞后，得先解决同步问题。
• 手动刷统计信息：在只读节点跑ANALYZE 你的表名;，强制更新表的统计数据，让优化器拿到最新的行数、字段分布情况。
• 检查索引有效性：执行SELECT * FROM pg_stat_user_indexes WHERE relname='你的表名';，看idx_scan有没有数值，idx_tup_read和idx_tup_fetch是不是正常，确认索引没被标记成无效。

其他实用技巧 #

• 临时强制走索引：对关键查询，可以用SELECT * FROM 表名 INDEX USING 索引名 WHERE ...;直接指定索引，适合应急，但别长期用，还是得从根源解决。
• 调高work_mem：如果Bitmap Scan需要处理大量数据，把work_mem设大一点（比如64MB），避免因为内存不够，优化器放弃Bitmap Scan。
• 同步主节点统计信息：主节点执行ANALYZE后，确认只读节点能及时同步统计数据（PolarDB默认自动同步，要是有延迟可以手动触发）。

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