PostgreSQL 9.6 Sum()聚合查询性能问题排查

嘿，我来帮你拆解下这个问题的来龙去脉和关键要点~

1. 索引未生效的核心原因 #

你创建了idx_shares_pool_miner_diff索引但初期查询没用到，执行VACUUM ANALYZE shares后索引就正常工作了——这俩操作刚好命中了问题的核心：

• 首先，PostgreSQL的查询优化器完全依赖准确的表统计信息来判断用不用索引。如果统计信息过时，它可能会误以为全表扫描比索引扫描更划算，ANALYZE就是用来更新这些统计数据的。
• 其次，MVCC带来的旧数据（dead tuples）确实会干扰索引的使用，尤其是索引仅扫描（Index-Only Scan）。如果表堆里有大量未清理的旧版本元组，PostgreSQL没法直接通过索引判断数据的可见性，只能被迫回表检查，这时候优化器干脆就放弃索引了。而VACUUM会清理这些dead tuples，同时更新表的可见性映射（VM），让索引仅扫描的条件满足。

2. 索引仅扫描的性能损耗点 #

翻查索引仅扫描的文档后，这类场景的性能损耗通常来自这几个地方：

• 可见性映射未覆盖的页面：如果某个数据页面不在VM里，PostgreSQL还是得回表确认元组可见性，额外的IO会拖慢速度。定期跑VACUUM就能维护好VM，减少这种情况。
• 索引碎片化或冗余：如果索引用久了产生很多碎片，或者包含了不必要的列，扫描时的内存和IO开销都会变大。可以用REINDEX idx_shares_pool_miner_diff重建索引，优化索引结构。
• 聚合运算本身的开销：哪怕用了索引，SUM()也得遍历所有符合条件的索引条目做累加，如果数据量特别大，CPU消耗也会很可观。要是这个查询执行得很频繁，不妨考虑用物化视图预先计算好聚合结果，定期刷新，查询时直接读物化视图就行。

3. 当前最优状态的合理性 #

你说在不启用并行工作进程的情况下已经是最优速度，这完全说得通：并行查询虽然能拆分任务加速，但也会带来进程调度的额外开销。当数据量或查询复杂度没达到阈值时，单进程的索引扫描反而更高效。等后续数据量上去了，再调整max_parallel_workers_per_gather这类参数开启并行也不迟。

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