nested loop在小驱动表+索引内表时天然高效，外表过滤后行数少且内表连接字段有高选择性索引时，开销为o(n×log m)；若内表无索引或存在隐式转换，则退化为o(n×m)，导致性能骤降。
Nested Loop在小驱动表+索引内表时天然高效
当外表过滤后只有几十或几百行，且内表连接字段有高选择性索引时，Nested Loop实际开销是 O(N × log M)，而非全表扫描的 O(N × M)。比如外表 200 行、内表 500 万行，有索引情况下仅需约 200 × 23 ≈ 4600 次索引查找——远低于 Hash Join 构建哈希表所需的内存分配、散列计算和探测开销。
常见错误现象是：执行计划显示 Nested Loop，但查询很慢。这时大概率是内表连接字段**没索引**，或存在隐式类型转换（如 INT vs VARCHAR）导致索引失效。
- 必须确认内表是否走
Index Scan或Index Only Scan，而不是Seq Scan - 用
EXPLAIN (ANALYZE, BUFFERS)查看内表节点的Actual Loops和Rows Removed by Filter - 外表加了
LIMIT但优化器未下推时，仍按全量估算，可能误选 NL；可尝试加OFFSET 0强制物化子查询
Hash Join受work_mem限制，内存不足就降级为磁盘哈希
PostgreSQL 的 Hash Join 严重依赖 work_mem。若 build table（小表侧）无法全放入内存，就会分片写入临时文件，后续探测阶段触发大量随机 I/O，性能断崖式下跌——此时 Nested Loop 反而更稳。
典型表现是：执行计划中出现 Hash Cond 但 Actual Time 明显拉长，且 Buffers: shared read=xxx 数值巨大；EXPLAIN ANALYZE 输出末尾还可能带 Warning: hash join cannot fit in memory。
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 检查当前会话
work_mem：运行SHOW work_mem - 临时调高（仅限当前查询）：
SET LOCAL work_mem = '256MB' - 但注意：
work_mem是每个操作符独立分配的，一个查询含多个 Hash Join 时总内存消耗会翻倍
Hash Join不适用非等值连接，而Nested Loop可以
Hash Join 仅支持等值连接（=），这是由哈希算法本身决定的；一旦 ON 条件含 、<code>>= 或函数表达式（如 ON a.id = b.parent_id + 1），优化器根本不会考虑它，只能退到 Nested Loop 或 Merge Join。
容易踩的坑是：以为加了索引就能触发 Hash Join，却忽略了语义限制。例如 LEFT JOIN ... ON t1.status IN ('A','B') 看似简单，但 IN 展开后本质是非等值逻辑，仍走 NL。
- 用
EXPLAIN确认Join Filter是否出现在Hash Join节点外（说明条件未能下推进哈希） - 若必须用范围条件，优先考虑
Merge Join（需连接列已排序）或补上覆盖索引 -
NOT EXISTS子查询常被转成Nested Loop Anti Join，这是合理且高效的，别强行改写成LEFT JOIN ... IS NULL
统计信息过期会让优化器误判NL成本
PostgreSQL 优化器估算 Nested Loop 成本时，高度依赖外表行数（cardinality）和内表索引选择性。如果 ANALYZE 长期未运行，统计信息陈旧，可能导致优化器高估 NL 开销、低估 Hash Join 效果，从而选错策略。
典型信号是：EXPLAIN 中 Rows 和 Actual Rows 差距巨大（比如预估 100 行，实际 10 万行），尤其在外表过滤条件后。
- 对关键表手动执行
ANALYZE table_name，或启用autovacuum_analyze_scale_factor - 避免在大表上频繁
UPDATE/DELETE后不做ANALYZE就跑 JOIN 查询 - 若某张表数据分布极不均匀（如 99% 值为 'active'），可建表达式索引并配合
ANALYZE收集扩展统计信息
