在 PostgreSQL 的查询优化器中，Merge Join 的选择基于一个关键假设：两侧输入按 join key 排序后，合并扫描的总成本 M+N 远低于嵌套循环的 M×N。当这一假设被基数估计偏差打破时，Merge Join 可能退化为排序成本爆炸的灾难性路径。本文从估计器的独立性假设与统计采样边界两个维度，解析偏差成因与工程化诊断框架。
PostgreSQL 的基数估计器默认采用列值独立性假设，即不同列的取值分布相互独立。当多列过滤条件或 join key 存在函数依赖时，独立假设会导致严重的估计偏差。以一个包含 3 亿条美国人口记录的表为例，若按州与邮编独立估计 brown_hair 与 NY 的交叉选择度，估算值约为 1000 万；但若邮编 10001 完全位于纽约州境内，实际交叉结果为 25000，偏差高达 15 倍。这种偏差在涉及相关列的 join 场景中同样存在，PostgreSQL 不会自动感知 join key 之间的隐含约束。
统计采样机制进一步放大了这一风险。autovacuum_analyze_scale_factor（默认 0.0001）与 autovacuum_analyze_threshold（默认 50）共同控制 ANALYZE 的触发阈值，约 30000 行采样即可满足要求。对于数亿行的大表而言，采样比例可能不足 0.001%，关键数据分布（如长尾值、倾斜键）在采样中缺失的概率显著上升。当 join key 存在热点倾斜时，Merge Join 估计可能严重低估实际输出行数，导致 planner 错误地选择 Merge Join 而非 Hash Join。
基数估计偏差引发的计划劣化呈现清晰的传导路径：低估输出行数 → planner 判断 Merge Join 成本更低 → 实际排序阶段数据量远超预期 → 排序溢出至磁盘或嵌套循环次数激增 → 查询延迟从毫秒级飙升至分钟级甚至超时。值得注意的是，PostgreSQL 17 引入了扩展统计信息机制，支持通过 CREATE STATISTICS 捕获列间函数依赖与 MCV 列表，但该特性需手动启用，默认配置下估计器仍受独立性假设约束。
工程实践中，诊断基数估计偏差应从三个入口切入。其一，查询 pg_stats 检查联合分布统计信息是否缺失；其二，通过 pg_mcv_info 直接读取 MCV 列表验证采样完整性；其三，运行 EXPLAIN ANALYZE 对比估计行数与实际行数的量级差异。当偏差超过一个数量级时，需评估是否为大表统计信息过期、相关列未创建扩展统计、或 join key 存在未捕获的倾斜分布。针对高频查询，可考虑针对性调优 effective_cache_size 与 work_mem 参数，或在应用层通过查询重写规避相关列 join。
资料来源：KnowingKen 博客对 PostgreSQL 统计信息与 join 策略关联性的深度分析。