统计信息是PostgreSQL查询优化的基础，影响扫描方式、连接策略和基数估算。通过ANALYZE收集的列级统计帮助规划器判断选择率，避免低效执行计划。例如，过时统计可能导致错误选择嵌套循环而非哈希连接。系统使用基于成本的优化器（CBO），依赖统计估算I/O与CPU成本，生成最优执行路径。两表连接时需准确预估过滤后行数以决定是否构建哈希表。若统计不准，会导致内存不足或路径选择错误。索引有效性也依赖统计，如低区分度字段（性别）通常不走索引。建议在大批量数据变更后手动运行ANALYZE；可通过调整default_statistics_target提高采样精度；对多列相关性可创建扩展统计：CREATE STATISTICS (dependencies) ON col1, col2 FROM table_name; 使用pg_stats视图查看统计信息，并用EXPLAIN ANALYZE验证执行计划中预估与实际行数的一致性，偏差大则需重新分析。保持统计准确是提升查询性能的关键措施。
PostgreSQL 查询性能在很大程度上依赖于查询规划器对数据分布的了解，而这些信息主要来自统计信息。统计信息帮助查询规划器判断使用哪种访问路径（如索引扫描还是顺序扫描）、连接方式（嵌套循环、哈希连接或归并连接）以及连接顺序，从而生成高效的执行计划。
统计信息如何影响查询
PostgreSQL 在表中收集列级别的统计信息，用于估算查询条件的选择率（selectivity），也就是满足 WHERE 条件的行数占比。这些统计信息默认存储在 pg_statistic 系统表中，由 ANALYZE 命令触发收集。
关键影响包括：
- 选择合适的扫描方式：如果某列的值分布显示某个查询条件会命中大量行，规划器可能放弃索引扫描而选择顺序扫描。
- 连接策略决策：统计信息能帮助判断两个表连接时的数据规模，决定使用哈希连接还是嵌套循环。
- 基数估算准确性：错误的统计可能导致基数（row count 估计）偏差，进而导致内存分配不足或选择低效的执行路径。
- 索引有效性判断：若统计显示某索引列区分度很低（如性别字段只有“男/女”），规划器通常不会使用该索引。
例如，一张用户表中有百万条记录，若未更新统计信息，系统仍认为表很小，可能会误选嵌套循环连接；而实际应使用哈希连接更高效。
查询计划生成机制
PostgreSQL 使用基于成本的查询优化器（Cost-Based Optimizer, CBO），通过估算不同执行路径的“成本”来选择最优计划。成本主要包括 I/O 成本和 CPU 成本。
生成过程大致如下：
- 解析 SQL 语句：生成语法树。
- 重写查询：应用规则（如视图展开、IN 改写等）。
- 生成候选执行计划：考虑各种扫描方式、连接顺序和连接算法的组合。
- 估算每种计划的成本：利用统计信息计算行数、选择率、磁盘读取页数等。
- 选择最低成本计划：最终执行该计划。
统计信息在这个过程中至关重要。比如，两表连接时，规划器需要知道每个表过滤后的输出行数，才能评估是否值得构建哈希表。如果统计过时，估算就会出错，可能导致选择明显低效的计划。
统计信息的更新与管理
统计信息不会实时更新，需手动或自动触发 ANALYZE。日常建议：
- 大批量数据变更（INSERT/UPDATE/DELETE）后运行 ANALYZE table_name。
- 调整 default_statistics_target 参数可增加采样精度（更高目标值收集更多直方图信息）。
- 对复杂条件或表达式索引，可创建扩展统计信息：
CREATE STATISTICS (dependencies) ON col1, col2 FROM table_name; - 查看统计信息可用：
SELECT * FROM pg_stats WHERE tablename = 'your_table';
查看与验证执行计划
使用 EXPLAIN 或 EXPLAIN ANALYZE 可查看实际执行计划，对比预估行数与实际行数是否接近。若差异大，说明统计信息不准，需重新分析。
例如：
EXPLAIN ANALYZE SELECT * FROM users WHERE age > 30;关注 “rows” 字段的预估（expected）与实际（actual）是否匹配。
基本上就这些。统计信息是 PostgreSQL 查询优化的基石，保持其准确是保障查询性能的关键措施之一。不复杂但容易忽略。
