数据面试：如何用 PostgreSQL 扩展统计信息修复基数误估？
题干与适用场景
一个 PostgreSQL 查询在单列过滤时很快，但同时过滤 customer_tier、region 和 status 时选择了错误的连接顺序。请诊断基数误估，并说明何时使用扩展统计信息、如何验证收益以及它的边界。
PostgreSQL 文档指出，默认统计信息主要按列收集；当多个列存在相关性时，独立性假设会让选择率相乘并产生误估。CREATE STATISTICS 可以收集依赖关系、最常见值组合或多变量直方图，但它不会替代索引，也不会让所有谓词都自动变准。
面试官考察点
- 是否先用
EXPLAIN (ANALYZE, BUFFERS)对比 estimated 与 actual rows。 - 是否能解释多列相关性导致的独立性假设错误。
- 是否区分
dependencies、mcv和ndistinct的适用场景。 - 是否知道扩展统计对象需要
ANALYZE才会获得数据。 - 是否用工作负载和回归查询验证计划改变，而不是凭感觉加统计对象。
- 是否说明采样、维护成本、表达式和跨表相关性的边界。
回答前需要澄清的问题
- 误估发生在过滤、连接还是分组？不同阶段需要不同诊断。
- 表大小、数据倾斜、更新频率和
defaultstatisticstarget是什么？ - 三个列是否同表、同一查询谓词，且相关性是否稳定？
- 计划问题是延迟、内存溢出、错误连接算法，还是资源成本？
- 是否已有合适索引、分区和新鲜的单列统计信息？
30 秒回答框架
我会先用实际执行计划确认估算行数在哪一步偏离，并检查统计信息新鲜度和数据分布。若同表多列有稳定相关性，再选择 dependencies、mcv 或 ndistinct 创建最小统计对象，运行 ANALYZE 后用代表性查询比较估算误差、连接算法、缓冲读和尾延迟。扩展统计只改善规划器信息，不替代索引、分区或数据建模；若相关性跨表、随时间变化或采样不足，就降低承诺并继续治理数据与计划。
分步骤深入解答
1. 定位估算误差
比较 EXPLAIN (ANALYZE, BUFFERS) 中每个节点的 estimated rows 与 actual rows，找出第一个数量级偏差。记录谓词、连接顺序、计划时间、执行时间和缓冲命中，避免只看总耗时。
2. 检查单列统计与新鲜度
确认最近一次 ANALYZE 覆盖了相关表，查看 pg_stats 的最常见值、直方图和非空比例。数据刚大量变更、强烈倾斜或统计目标过低时，先修复采样和更新节奏，再判断是否需要扩展统计。
3. 选择统计类型
dependencies 描述列之间的功能依赖，适合一个列强烈暗示另一个列的场景；mcv 描述多列最常见组合，适合少数组合主导选择率；ndistinct 估计多列组合的不同值数量，适合分组或去重基数问题。一个对象可以指定多个类型，但应以实际误差为依据。
CREATE STATISTICS orders_customer_region_stats
(dependencies, mcv, ndistinct)
ON customer_tier, region, status
FROM orders;
ANALYZE orders;4. 重新验证计划
在生产相似的参数、缓存状态和并发下重跑查询，比较每个关键节点的行数误差、连接方法、内存、磁盘临时文件和 p95/p99。计划改变不等于一定更好；要确认总资源和稳定性都改善，并观察参数不同的查询。
5. 处理采样与统计目标
扩展统计仍基于采样，稀有组合或快速变化的数据可能没有被捕获。对热点列提高统计目标前，先测量 ANALYZE 时间、系统负载和收益；不要把全局目标盲目调到最大。统计对象的列集合也应尽量小，避免维护无用组合。
6. 说明边界和替代方案
扩展统计只描述同一表的列关系，不能直接建模跨表相关性，也不会改变索引访问路径。跨表问题可能需要重写查询、预聚合、分区、物化结果或改进数据模型；相关性随租户、季节或状态转移变化时，需要持续监控而非一次性修复。
7. 建立回归与清理机制
把代表性计划和估算误差写入回归集合，在 PostgreSQL 升级、数据迁移和 schema 变化后复测。若统计对象长期没有改善、只服务已删除查询或增加维护成本，应删除并记录原因。用查询指纹关联统计对象、计划变化和线上延迟。
高质量示范回答
我会先找出计划中第一个 estimated rows 与 actual rows 相差数量级的节点，并确认单列统计已经新鲜。假设三个列在同一张订单表中存在稳定组合，我会先创建最小的 dependencies 或 mcv 对象，运行 ANALYZE，再用代表性参数比较估算误差、连接顺序、缓冲读和尾延迟。若是分组或去重的组合基数问题，再评估 ndistinct。
我不会把扩展统计当成索引替代品，也不会承诺跨表相关性自动解决。对于稀有组合、快速变化数据或采样不足，我会测量更高统计目标的成本，必要时改写查询、预聚合或调整模型。最终将计划和估算误差纳入回归集合，持续检查收益是否仍存在。
常见错误
- 只看总耗时不看节点误差 → 找不到误估源头 → 逐节点比较 estimated 与 actual rows。
- 把三种统计类型全部默认打开 → 增加维护而未必有收益 → 依据误差形态选择最小集合。
- 创建对象后不运行
ANALYZE→ 规划器没有新数据 → 明确刷新和验证步骤。 - 认为扩展统计会创建索引 → 仍可能扫描大量数据 → 分开讨论统计信息和访问路径。
- 用一次参数的计划证明普遍有效 → 数据分布和参数会变化 → 做多参数、并发和回归验证。
- 忽略跨表相关性 → 单表统计无法解决连接误估 → 改写查询或治理模型。
追问及应对
什么时候优先选 dependencies？
当一个列几乎决定另一个列，例如区域与受限状态有稳定函数关系时。先用计划误差和数据检查证明依赖，再创建对象。
mcv 与 ndistinct 如何区分？
mcv 关注多列最常见组合对过滤选择率的影响；ndistinct 关注组合值数量，常用于分组、去重或连接基数估计。
扩展统计对象会自动更新吗？
统计数据在 ANALYZE 时收集，需依靠自动或手动 ANALYZE 触发。对象定义存在不等于数据已经新鲜。
为什么提高统计目标可能仍无效？
采样仍可能遗漏稀有组合，数据关系也可能随时间变化。应观察估算误差和 ANALYZE 成本，必要时改用模型或查询策略。
如何验证没有回归？
保存多组参数的计划，比较估算误差、资源、p95/p99 和临时文件，并在版本、数据量和 schema 变化后重跑。
什么时候删除扩展统计？
当查询已消失、误差没有改善或维护成本超过收益时删除，并保留原因和前后指标，避免统计对象无限累积。