Nested Loops JOIN成本飙升主因是外层行数远超估算且内表缺索引，导致每轮循环触发全表扫描；快速验证方法是会话级执行SET enable_nestloop = off，若计划秒切Hash/Merge Join且耗时骤降即坐实问题。

直接关掉 enable_nestloop 是最快验证和缓解 Nested Loops JOIN 成本过高的手段，尤其当驱动表实际行数远超估算、内表又缺索引时。

为什么Nested Loops JOIN成本会突然飙升？

Nested Loops 本质是“外层每行 × 内层查一次”，一旦外层实际返回几千甚至几十万行，而内表连接字段没索引，就会触发成千上万次全表扫描（Seq Scan）或低效索引扫描（Index Scan 后高 Rows Removed by Filter）。常见信号包括：

• 执行计划里 Nested Loop 节点下方紧跟着 Seq Scan on table_b，且 actual rows 远大于 rows 估算值
• EXPLAIN (ANALYZE, BUFFERS) 显示该节点 Buffers: shared read=xxx 极高，说明反复读盘
• SQL 第一次执行就卡住，explain analyze 输出迟迟不结束——很可能正在做百万级嵌套比较

怎么快速验证是不是NL导致的瓶颈？

不改SQL、不加索引，用会话级开关强制绕过 NL，看执行计划是否立刻切换为 Hash Join 或 Merge Join：

• 执行 SET enable_nestloop = off;（PostgreSQL / 金仓/KES）
• 再跑 EXPLAIN (ANALYZE, BUFFERS) SELECT ...;
• 如果计划秒出、出现 Hash Join 且耗时骤降，基本坐实问题
• 注意：该设置仅对当前连接有效；若发现 enable_hashjoin=off，需先补 SET enable_hashjoin = on;

关掉NL后还慢？检查这三个隐性陷阱

很多人设了 enable_nestloop = off 就以为完事，但实际可能卡在更底层：

• JOIN 字段类型不一致（比如 INT vs VARCHAR），导致即使走 Hash Join，内表也得 Seq Scan —— 检查 ON a.id = b.a_id 两边是否同类型
• 统计信息陈旧：ANALYZE table_name; 比建索引更能影响优化器选型，尤其金仓 V8R6 对统计滞后敏感
• Hash Join spill 到磁盘：work_mem 不足时，哈希表写临时文件，I/O 暴增；此时调大 work_mem 比回退到 NL 更有效

真正难处理的不是 NL 本身，而是它背后暴露的索引缺失、统计失真、类型隐式转换这些“静默缺陷”——它们在 NL 关闭后仍会拖垮 Hash/Merge Join。