sql统计查询扫描过多的核心问题是索引未有效利用或过滤能力弱；应通过explain analyze检查rows removed by filter占比高或index scan行数远超actual rows来定位低效原因。
SQL统计查询扫描过多，核心问题通常是索引未被有效利用或现有索引过滤能力弱。提升索引过滤率的关键在于让数据库在执行计划中尽早排除不匹配行，减少实际扫描的数据页数量。
确认低效扫描的真实原因
先用 EXPLAIN ANALYZE 查看执行计划，重点关注：
- Rows Removed by Filter 占比高（如 >80%），说明索引范围大但实际匹配少，过滤率差
- Index Scan 扫描行数远大于 Actual Rows，表明索引选择性不足
- Bitmap Heap Scan 或全表扫描（Seq Scan），可能缺索引或条件无法走索引
针对性优化索引结构
避免“一个字段一个索引”，按查询模式构建高选择性复合索引：
- 将 WHERE 等值条件字段放最前（如
status = 'done'），再跟 范围字段（如created_at > '2024-01-01'），最后是 ORDER BY / SELECT 字段 - 对高频统计字段（如
COUNT(*)、SUM(amount)）考虑 覆盖索引，把 SELECT 中的列也加入索引（用INCLUDE或作为索引尾部字段） - 区分 高基数字段（如 user_id）和 低基数字段（如 status），低基数字段单独建索引效果差，应作为复合索引的前导位或配合表达式索引
精简查询逻辑与数据分布适配
索引再好，也救不了设计失当的查询：
- 避免在 WHERE 中对索引字段使用函数或运算（如
YEAR(created_at) = 2024），改用范围写法：created_at >= '2024-01-01' AND created_at - 统计类查询若允许近似结果，可启用 pg_statistic_ext 或使用
TABLESAMPLE降低扫描量 - 定期运行 ANALYZE 更新统计信息，尤其在大批量导入/删除后，防止优化器误判选择性
验证与持续观察
优化不是一劳永逸：
- 上线后对比 Execution Time 和 Shared Hit Blocks，确认物理I/O下降
- 监控 index_hit_rate（可通过
pg_statio_user_indexes计算），长期低于 95% 需复盘索引有效性 - 对写入频繁的表，注意新增索引带来的 INSERT/UPDATE 延迟，权衡读写负载
不复杂但容易忽略：过滤率提升本质是让索引“更准”而不是“更多”，重点在理解查询谓词分布和数据特性，而非堆砌索引。
