Nested Loop本身不触发外层全表扫描，而是外层表访问路径选择不当所致；若无有效索引、统计信息过期或WHERE条件无法下推，优化器会选Seq Scan，导致即使只需10行也要扫描百万行。
为什么Nested Loop会触发外层全表扫描
PostgreSQL选择Nested Loop时，不会自动对外层表加索引过滤；它只保证“外层每行驱动一次内层查找”，但外层本身是否走索引、是否被WHERE条件提前剪枝，完全取决于外层表的访问路径（Scan方式）。如果外层表没索引、或WHERE条件无法下推、或统计信息过期，优化器就可能选Seq Scan——哪怕你只想要10行结果，它也得先扫完外层全部百万行。
用EXPLAIN ANALYZE确认外层是否真在全表扫描
别只看EXPLAIN的预估计划，必须跑EXPLAIN ANALYZE。重点盯三处：
- 外层节点是否标着
Seq Scan on table_name（而不是Index Scan或Bitmap Index Scan） - 外层节点的
Rows Removed by Filter是否远大于Actual Rows（比如扫了100万行，只留下5行，说明WHERE没生效或没走索引） - 整个计划里
Nested Loop节点上方是否没有Limit或Sort等提前终止操作——这意味着外层必须全部产出才能往下传
外层避免全表扫描的实操手段
核心思路：让外层表的访问路径变窄，不是靠Nested Loop本身，而是靠外层自身的执行方式。
- 给外层表的WHERE字段建B-tree索引，尤其注意复合索引顺序：比如
WHERE status = 'active' AND created_at > '2025-01-01'，索引应为CREATE INDEX idx_orders_status_created ON orders(status, created_at) - 检查
pg_stats中该表的统计信息是否新鲜：SELECT last_analyze, n_tup_ins, n_tup_upd FROM pg_stat_all_tables WHERE relname = 'orders';如果last_analyze是几个月前，立刻ANALYZE orders; - 避免在WHERE中对列做函数操作：
WHERE UPPER(email) = 'A@B.COM'会让索引失效；改用WHERE email = 'a@b.com'+LOWER()索引，或直接用citext类型 - 如果外层只是临时筛选小结果集，考虑用CTE或子查询显式物化：
WITH active_users AS (SELECT id FROM users WHERE status = 'active') SELECT * FROM active_users u JOIN orders o ON o.user_id = u.id;这能强制优化器先算子查询，再把几百个id当参数传给Nested Loop内层
容易被忽略的隐性陷阱
外层看似有索引，但依然走Seq Scan，常见原因不是索引没建，而是：
- 查询中用了
OR条件且分支无法共用同一索引，比如WHERE a = 1 OR b = 2，即使a、b各自有索引，优化器也可能放弃索引走全扫 - JOIN条件和WHERE混写导致条件下推失败，例如
LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.status IS NOT NULL，这实际把LEFT JOIN退化成INNER JOIN，但优化器未必能重写，外层仍被迫全扫后再过滤 -
work_mem设得太小，导致本可走Index Scan + Bitmap Heap Scan的路径因内存不足被降级为Seq Scan
真正卡住性能的，往往不是Nested Loop本身，而是外层那张没被约束住的表——它像一辆没刹住的卡车，后面挂再多高效索引也白搭。
