PostgreSQL 行数估算 1 行、实际 1 万行：多列相关导致 Nested Loop 扫了 999 万次，CREATE STATISTICS 后 1 秒降到 12ms

pg_stats 里这几列的 n_distinct：region_id 10、province_id 10、city_id 100、warehouse_id 100。规划器默认各列独立，选择率 ≈ 1/10 × 1/10 × 1/100 × 1/100 = 1/100 万，乘以 100 万行，再向上取整就是 rows=1。真实情况是 city_id = 37 已经决定了省和仓库，另外三个条件一行都过滤不掉，实际 10000 行。

只看前两列也能看到偏差：索引条件 province_id = 4 AND city_id = 37 的 Bitmap Index Scan 估算 904–1097 行（每次 ANALYZE 抽样不同，数字会变），实际 10000 行；再叠上 region_id、warehouse_id 两个过滤条件，估算一路掉到 1。

我先试了最常见的「统计不准就加大统计目标」：把四列 SET STATISTICS 1000 再 ANALYZE，估算仍然是 rows=1，JOIN 仍然 943.5ms。单列的直方图和高频值再准，也只描述单列，不知道 city_id 和 province_id 的关系。

JOIN 语句：SELECT count(*), sum(o.amount), sum(t.monthly_target) FROM orders o JOIN district_targets t ON t.district_id = o.district_id WHERE 上面四个条件。规划器认为 orders 只出 1 行，对 1 行做 Nested Loop、内层扫一遍 1000 行的小表（cost 18）是最便宜的方案，Hash Join 还要多建一次哈希表。

实际是 10000 行，内层 Seq Scan on district_targets 的 loops=10000、每次 1000 行，Join Filter 一共丢掉 9,990,000 行。orders 这边的 Bitmap Heap Scan 只用了 18–21ms，剩下 970ms 左右都耗在反复扫小表上。

这也是我觉得这类问题难查的地方：两张表都不大，单独查都很快，SQL 也没写错，慢的只是计划。看 EXPLAIN ANALYZE 时盯住两处：最底层 orders 扫描的 rows=1 vs actual rows=10000，以及 Rows Removed by Join Filter 的数量级。

看到小表被 Seq Scan 了 10000 遍，我第一反应是「小表没索引」，于是 ALTER TABLE district_targets ADD PRIMARY KEY (district_id)。结果计划还是 Nested Loop + Seq Scan，没有换成索引扫描；时间从约 1 秒降到 373–495ms。

用 EXPLAIN (ANALYZE, VERBOSE) 看才明白：Nested Loop 多了一行 Inner Unique: true。主键告诉规划器小表每个 district_id 只有一行，内层扫到匹配就停，不用扫完 1000 行；本次匹配的区县编号是 361–370，平均每次扫 366 行，Rows Removed by Join Filter 从 9,990,000 降到 3,645,000。省下来的是这部分，根因（估算 1 行）没动，所以规划器仍然觉得「扫一遍小表很便宜」。

所以加主键是对的（这张表本来就该有），但它不是这条 SQL 的解法；估算不改，换一组条件或数据量再大一点，同样的问题还会出现。

CREATE STATISTICS st_orders_area_dep (dependencies) ON region_id, province_id, city_id, warehouse_id FROM orders; 然后 ANALYZE orders。建统计对象本身 1.5ms，ANALYZE 100 万行 210.6ms / 233.5ms。pg_stats_ext 里能看到函数依赖系数，例如 "3 => 2": 1.000000（city_id 决定 province_id），本例全部是 1.0，因为数据就是这么造的。

之后单表估算 10000（第二轮 10100），JOIN 计划换成：district_targets 做外层（1000 行），每个 district_id 到 orders 的 idx_orders_area 上做 Index Scan（loops=1000，平均每次 10 行），12.7 / 11.2ms、15.0 / 18.8ms。

换成 (mcv) 也能修：ANALYZE 116.3ms / 159.2ms，估算 9367 / 9300，计划和耗时与 dependencies 基本一样。我的取舍（经验判断）：列之间是「上级决定下级」这种层级关系，用 dependencies，体积小；值分布很偏、某几个组合特别多时，用 mcv；也可以两种一起建。dependencies 只对等值条件（以及 IN）生效，范围条件用不上，这一点见文末官方文档。

只读 SQL 一共 4 段，开头 SET statement_timeout = '30s'。第 1 段列出已有扩展统计和类型（stxkind：d=ndistinct、f=dependencies、m=mcv），以及 ANALYZE 后有没有数据；第 2 段列出有多列索引、但还没建任何扩展统计的表（多列一起出现在条件里，最可能相关）；第 3 段列这些索引列各自的 n_distinct；第 4 段用 TABLESAMPLE SYSTEM (1) 抽约 1% 的页，比较两列各自的去重数和组合去重数。

测试库上的输出：第 2 段找到 orders.idx_orders_area（province_id, city_id, district_id）；第 3 段 n_distinct 分别是 10 / 100 / 1000；第 4 段抽到约 1 万行，city 100 个、district 1000 个、组合也是 1000 个，组合数等于其中较大的那个，说明 district 决定 city。

我写第 1 段时把 stxkind 的字母记反了，以为 d 是 dependencies。实际建了一个 (dependencies, mcv) 的统计对象一查，kinds 显示 {f,m}：f 才是函数依赖（dependencies），d 是 ndistinct。脚本里的注释已按实测改正。