lateral子查询列不能用于外部where，因其执行晚于外部表扫描，列属后置计算结果，作用域受限；须将过滤条件下推至子查询内。
为什么 LATERAL JOIN 的子查询列不能直接用在外部 WHERE 中
因为 LATERAL 子查询的执行时机晚于外部表扫描，其输出列在逻辑上属于“后置计算结果”，SQL 标准不允许在外部 WHERE（即 FROM 阶段之前）引用这些列。常见错误是写成：
SELECT * FROM orders o LATERAL (SELECT item_id FROM order_items WHERE order_id = o.id) AS i WHERE i.item_id = 123——这会报错
column "i.item_id" does not exist，不是语法问题，而是作用域限制。
实操建议：
- 把过滤条件下推到子查询内部：把
WHERE i.item_id = 123改成子查询里的WHERE order_id = o.id AND item_id = 123 - 若需多条件组合筛选，优先在子查询中用
AND连接，而不是依赖外部WHERE - PostgreSQL 14+ 支持在
LATERAL子查询中使用OFFSET/FETCH，但若外部有ORDER BY+LIMIT，注意子查询是否被提前剪枝
LATERAL 子查询里用 SELECT * 为什么慢
不是语法错，是隐式列膨胀陷阱。当子查询写成 SELECT * FROM json_to_recordset(o.items)，而 o.items 是一个含 50 个字段的 JSON 数组时，PostgreSQL 会为每行生成全部 50 列，哪怕后续只用其中 2 列。CPU 和内存压力陡增，尤其在大表关联时。
实操建议：
- 永远显式列出需要的列：
SELECT id, qty, sku FROM json_to_recordset(o.items) AS x(id int, qty int, sku text) - 如果子查询来自函数（如
generate_series），确认返回类型是否带冗余字段；用\df+ function_name查看定义 - 对嵌套 JSON 处理，先用
jsonb_path_query_array提取顶层数组，再用LATERAL展开，比直接jsonb_to_recordset更可控
用 LATERAL 替代 UNNEST 时索引失效的典型场景
比如想查每个用户最近 3 条订单，写成：
SELECT u.name, o.* FROM users u LATERAL (SELECT * FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 3) o——看起来合理，但如果
orders(user_id, created_at) 没有复合索引，PostgreSQL 可能放弃索引扫描，改用嵌套循环 + 全表排序，性能断崖下跌。
实操建议：
- 必须建立覆盖查询条件的复合索引：
CREATE INDEX idx_orders_user_created ON orders (user_id, created_at DESC) - 避免在
LATERAL子查询中对关联字段做函数操作，例如WHERE lower(user_id::text) = lower(u.id::text)，会导致索引无法使用 - 用
EXPLAIN (ANALYZE, BUFFERS)看实际执行计划，重点确认子查询是否走了Index Scan using ...而非Seq Scan
多个 LATERAL 连续展开时，中间结果不物化导致重复计算
PostgreSQL 默认不对 LATERAL 子查询结果做物化（materialize），如果后续还有另一个 LATERAL 引用前一个的结果，引擎可能反复执行前一个子查询。例如：
SELECT * FROM t LATERAL (SELECT avg(x) FROM unnest(t.vals) x) a LATERAL (SELECT x > a.avg FROM unnest(t.vals) x) b——
unnest(t.vals) 被执行了两次。
实操建议：
- 用 CTE 显式物化中间结果（仅限 PostgreSQL）：
WITH expanded AS (SELECT t.*, avg(x) avg_val FROM t, unnest(t.vals) x GROUP BY t.id) SELECT * FROM expanded e LATERAL (SELECT x > e.avg_val FROM unnest(e.vals) x)
- 或者改用子查询封装：
(SELECT * FROM (SELECT avg(x) FROM unnest(t.vals) x) AS _avg)，强制优化器识别为单次计算 - 注意：CTE 在 PG 中默认物化，但 12+ 版本可能自动内联，加
MATERIALIZED关键字更稳妥
真正影响性能的往往不是 LATERAL 本身，而是子查询里那些没被索引覆盖的过滤、没被剪枝的列、以及被重复触发的计算逻辑——这些点在 explain 里都藏得比较深，得一条一条拆开看执行节点的实际 rows 和 loops。
