全表扫描常因索引未命中导致，应避免函数操作和类型转换，优先使用等值或范围条件以提升索引命中率。
在PostgreSQL中，全表扫描（Sequential Scan）通常出现在查询无法有效使用索引的场景下。虽然全表扫描在某些情况下是合理的（比如小表或返回大量数据），但当表数据量大、查询性能下降时，就需要优化过滤条件和索引设计来避免不必要的全表扫描。
合理设计过滤条件以提升索引命中率
过滤条件的设计直接影响执行计划是否选择索引扫描。以下是一些关键原则：
- 避免对字段进行函数操作：如WHERE UPPER(name) = 'JOHN'会导致索引失效。应保持字段“原样”，可考虑创建函数索引解决。
- 避免隐式类型转换：例如字段是VARCHAR，但用数字比较WHERE code = 123，会触发类型转换，影响索引使用。
- 优先使用等值、范围条件：如=, >, 这些操作符更容易匹配B-tree索引。
- 慎用OR连接多个条件：特别是跨字段的OR可能导致索引失效，可考虑拆分为UNION ALL或使用位图扫描。
- LIKE查询注意前导通配符：LIKE 'abc%'可用索引，但LIKE '%abc'通常不行，除非使用GIN索引配合text_pattern_ops。
为高频过滤字段建立合适索引
即使条件写得正确，没有索引也难以避免全表扫描。应根据查询模式创建索引：
- 单列索引：对频繁用于过滤的字段单独建索引，如status, created_at。
- 复合索引注意顺序：遵循“最左前缀”原则。例如查询条件是WHERE a = 1 AND b = 2，应建立(a,b)索引，而不是(b,a)。
- 覆盖索引减少回表：将SELECT中常用字段包含在索引中（使用INCLUDE子句），避免访问主表数据。
- 选择性高的字段优先：选择性越高（即唯一值越多），索引效率越高。低选择性字段（如性别）单独建索引意义不大。
利用统计信息与执行计划分析
PostgreSQL依赖统计信息决定是否走索引。定期更新统计有助于优化器做出正确判断：
- 运行ANALYZE table_name;更新统计信息，特别是在大批量导入或删除后。
- 使用EXPLAIN (ANALYZE, BUFFERS)查看实际执行计划，确认是否走了预期索引。
- 关注rows预估与实际是否接近，偏差大可能需调整default_statistics_target或手动设置列统计目标。
控制查询返回的数据量
即使有索引，如果查询返回大量行，优化器可能仍选择全表扫描，因为随机IO成本高。可通过以下方式缓解：
- 加LIMIT限制返回条数，尤其是分页查询。
- 避免SELECT *，只取必要字段，减少IO压力。
- 使用分页或时间分区，缩小扫描范围。
基本上就这些。关键是在理解查询模式的基础上，合理设计过滤条件并配合索引策略，同时借助执行计划持续验证优化效果。不复杂但容易忽略细节。
