Nested Loops JOIN 过慢主因是被误用于大数据量场景：驱动表过大、内表缺索引或优化器统计误判；临时禁用 enable_nestloop=off 可快速切换至 Hash/Merge Join，验证并解决性能瓶颈。
Nested Loops JOIN 过慢不是算法本身错了，而是它被用在了不该用的地方——通常意味着驱动表太大、内表没索引，或优化器误判了连接顺序。直接关掉 enable_nestloop 往往比调优更有效。
为什么Nested Loops JOIN会突然变慢？
它本质是“外层每行 × 内层全扫一遍”，时间复杂度接近 O(N×M)。一旦外层结果集超 1000 行，而内层又没索引，就会卡住：
- 执行计划里出现
Seq Scan或Index Scan后紧跟着Nested Loop，且Rows Removed by Filter很高 → 说明大量行在循环中被丢弃 - SQL 第一次执行就慢（无缓存），且
explain analyze卡在输出阶段 → 很可能正在做百万级嵌套比较 - 金仓/KES 中
enable_hashjoin=on但依然选 NL → 优化器误估了统计信息，或内表行数被低估
临时绕过：当前会话禁用 NestLoop
不改 SQL、不加索引，最快验证是否是 NL 导致的瓶颈：
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 执行
SET enable_nestloop = off;，再跑explain analyze—— 如果执行计划秒出、出现Hash Join或Merge Join，基本坐实问题 - 注意：该设置仅对当前连接生效，断开即恢复；适合排查和紧急压测，不能上生产
- 若同时发现
enable_hashjoin=off或enable_mergejoin=off，需先补上SET enable_hashjoin = on;
长期方案：用户级关闭 + 索引补位
永久规避 NL 被误选，但必须配合索引，否则 Hash/Merge 也会因数据倾斜而崩：
- 在主节点执行
ALTER USER username SET enable_nestloop = off;—— 集群自动同步，无需重启 - 检查所有 JOIN 条件字段：外键列、ON 子句中的列，必须在被驱动表上有索引；例如
ON a.id = b.a_id，则b.a_id必须有索引 - 避免
RIGHT JOIN或FULL OUTER JOIN触发 NL：这类连接金仓默认倾向 NL，优先改写为LEFT JOIN+ 显式过滤
容易被忽略的关键点
很多人关了 enable_nestloop 就以为万事大吉，但实际还有两个隐性陷阱：
-
JOIN字段类型不一致（比如一边是INT，一边是TEXT）会导致索引失效，即使开了 Hash Join 也得走 Seq Scan - 金仓 V8R6 的统计信息更新滞后：执行
ANALYZE table_name;比单纯建索引更能影响优化器选型 -
SET enable_nestloop = off后，如果数据量极大且内存不足，Hash Join可能 spill 到磁盘，反而更慢——此时得调work_mem，而不是回退到 NL
