合理使用索引、优化统计信息、利用分区表和调整配置参数可减少PostgreSQL数据扫描。通过创建合适索引避免全表扫描，定期更新统计信息以提升执行计划准确性，采用分区剪枝缩小查询范围，并根据存储介质调整代价参数，使优化器优先选择高效扫描路径，从而降低I/O开销并提升查询性能。
在PostgreSQL中，减少数据扫描是提升查询性能的关键。通过合理调整扫描路径，可以让查询优化器选择更高效的执行计划，从而降低I/O开销和响应时间。核心思路是让数据库尽可能少读数据页，优先使用索引、条件下推和分区裁剪等机制。
1. 合理使用索引避免全表扫描
全表扫描（Sequential Scan）通常发生在没有合适索引或查询条件无法利用现有索引时。要减少这种扫描：
- 为常用查询字段创建索引：如WHERE、JOIN、ORDER BY中涉及的列。
- 使用复合索引：对于多条件查询，组合索引比多个单列索引更高效。
- 考虑部分索引：如果只查询特定状态的数据（如status = 'active'），可建立CREATE INDEX ... WHERE status = 'active'，减小索引体积并提升命中率。
- 避免在索引列上使用函数或表达式：如WHERE UPPER(name) = 'JOHN'会跳过索引，应改用函数索引或直接比较。
2. 优化查询条件与统计信息
PostgreSQL依赖统计信息估算不同扫描路径的代价。若统计不准，可能误选全表扫描。
- 定期运行ANALYZE：确保表的统计信息最新，特别是频繁更新的大表。
- 调整default_statistics_target：对复杂查询或大表，提高该值可增强统计精度，帮助优化器做出更好决策。
- 使用EXPLAIN分析执行计划：查看是否走了索引扫描（Index Scan/Bitmap Index Scan），还是被迫全表扫描。
3. 利用分区表减少扫描范围
对于大表，按时间或类别分区能显著减少扫描数据量。
- 使用声明式分区：如按月分区日志表，查询某个月的数据只会扫描对应分区。
- 确保分区键在查询条件中出现：这样优化器才能进行“分区剪枝”（Partition Pruning），跳过无关分区。
- 结合局部索引：每个分区可拥有自己的索引，进一步缩小扫描范围。
4. 调整配置引导优化器选择
某些参数会影响优化器对扫描路径的权衡。
- random_page_cost：如果使用SSD，可将其从默认4降到1.1~2，使索引扫描更具吸引力。
- enable_seqscan：测试时可临时设为off，强制走索引，但生产环境不建议关闭。
- cpu_tuple_cost 和 cpu_index_tuple_cost：微调这些代价因子，可在特定负载下影响路径选择。
基本上就这些。关键不是完全消除顺序扫描，而是让每次扫描都“物有所值”。合适的索引、准确的统计、合理的分区设计，配合对执行计划的理解，就能有效控制扫描行为，提升整体查询效率。
