Nested Loop Join 在 PostgreSQL 里名声不太好：一旦外层结果集比规划器预估的大得多，它就可能把一次查询变成成千上万次索引探测，延迟瞬间爆炸。但问题通常不在 Nested Loop 本身，而在规划器对行数的判断失准。enable_nestloop 是一个很有用的诊断旋钮，却不应该被当成长期性能药方。
enable_nestloop 到底控制什么
enable_nestloop 是 PostgreSQL 的一个 GUC 参数，用来影响查询规划器是否倾向使用 Nested Loop Join。它不是硬性禁用所有 Nested Loop：某些查询形态只能用 Nested Loop，规划器仍可能选择它。
可以在会话级别临时调整：
SET enable_nestloop = off;
EXPLAIN (ANALYZE, BUFFERS)
SELECT ...;
RESET enable_nestloop;
这类开关最适合回答一个问题：如果规划器不走 Nested Loop，查询会不会更快？如果答案是“会”，下一步不该是把参数全局关掉，而是追查为什么 PostgreSQL 低估或高估了参与 Join 的行数。
Nested Loop 什么时候很快，什么时候很惨
Nested Loop 的工作方式可以粗略理解为：外层表每拿到一行，就去内层表找匹配行。外层很小、内层有高选择性索引时，它非常快。
典型的好场景：
- 根据主键或唯一键查少量记录。
- 外层过滤后只有几十行。
- 内层 Join 条件能命中合适索引。
LIMIT很小，且规划器能利用索引快速返回。
灾难通常出现在另一个方向：规划器以为外层只有 100 行，实际跑出 100 万行；于是它选择 Nested Loop，而不是 Hash Join 或 Merge Join。查询计划看起来“合理”，运行时却不断重复访问内层表，I/O 和 CPU 都被放大。
用一个可改造的例子定位问题
下面的例子可以在本地 PostgreSQL 里直接运行。它不是为了复现某篇文章的具体数据，而是演示如何对比 enable_nestloop 前后的计划，并观察“预估行数”和“实际行数”的差距。
DROP TABLE IF EXISTS orders;
DROP TABLE IF EXISTS customers;
CREATE TABLE customers (
id bigint PRIMARY KEY,
country text NOT NULL
);
CREATE TABLE orders (
id bigint PRIMARY KEY,
customer_id bigint NOT NULL REFERENCES customers(id),
status text NOT NULL,
created_at timestamptz NOT NULL DEFAULT now()
);
INSERT INTO customers
SELECT i, CASE WHEN i <= 90000 THEN 'US' ELSE 'CA' END
FROM generate_series(1, 100000) AS i;
INSERT INTO orders
SELECT i,
(random() * 99999 + 1)::bigint,
CASE WHEN random() < 0.9 THEN 'paid' ELSE 'pending' END,
now() - (random() * interval '30 days')
FROM generate_series(1, 1000000) AS i;
CREATE INDEX orders_customer_id_idx ON orders(customer_id);
CREATE INDEX orders_status_idx ON orders(status);
ANALYZE customers;
ANALYZE orders;
EXPLAIN (ANALYZE, BUFFERS)
SELECT c.country, count(*)
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.country = 'US'
AND o.status = 'paid'
GROUP BY c.country;
SET enable_nestloop = off;
EXPLAIN (ANALYZE, BUFFERS)
SELECT c.country, count(*)
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE c.country = 'US'
AND o.status = 'paid'
GROUP BY c.country;
RESET enable_nestloop;
看计划时重点盯这几处：
rows=：规划器预估的行数。actual rows=：真实执行时返回的行数。- Join 节点类型：
Nested Loop、Hash Join或Merge Join。 Buffers：是否出现大量重复读取。- 总耗时是否因为关闭 Nested Loop 明显下降。
如果关闭 Nested Loop 后快很多，基本可以判断：Nested Loop 是症状，统计信息或查询形态才是病因。
更稳的修复方向：让规划器看清楚
优先考虑这些修复，而不是把 enable_nestloop = off 写进全局配置：
-- 1. 刷新统计信息
ANALYZE customers;
ANALYZE orders;
-- 2. 对分布不均的列提高统计目标
ALTER TABLE customers ALTER COLUMN country SET STATISTICS 1000;
ALTER TABLE orders ALTER COLUMN status SET STATISTICS 1000;
ANALYZE customers;
ANALYZE orders;
-- 3. 如果列之间存在相关性，可以考虑扩展统计信息
CREATE STATISTICS orders_customer_status_stats
ON customer_id, status
FROM orders;
ANALYZE orders;
可以这样实践：先在单个慢查询会话里 SET enable_nestloop = off 做 A/B 对比，再用 EXPLAIN (ANALYZE, BUFFERS) 找出估算偏差最大的节点。修好统计信息、索引或 SQL 形态后，再把参数恢复默认。
采用建议：把它当手电筒，不当拐杖
enable_nestloop 的价值在于照亮问题：它能快速告诉你“如果不用 Nested Loop，是否会更好”。但生产环境长期关闭它，可能让原本适合 Nested Loop 的小结果集查询变慢。
一个实用检查清单：
- 只在会话级别或测试环境临时关闭。
- 对比关闭前后的
EXPLAIN (ANALYZE, BUFFERS)。 - 重点检查预估行数和实际行数的倍率差。
- 优先修复统计信息、扩展统计、索引和查询条件。
- 不要因为一次慢查询就全局禁用 Nested Loop。
Nested Loop 不可怕，可怕的是规划器带着错误地图上路。把行数估准，PostgreSQL 通常能自己选出更合适的 Join 策略。