普通子查询无法引用外层表字段，因SQL标准要求其独立执行；必须用LATERAL显式声明，且仅限FROM子句中，配合明确别名使用。
为什么普通子查询引用外层表会报 ERROR: invalid reference to FROM-clause entry
因为标准 SQL 规定：非 LATERAL 子查询必须独立执行，不能感知外部作用域。优化器把它当“一次性预计算”，根本没打算让它看到 orders.id 这种左表字段。
常见误写：SELECT * FROM orders, (SELECT * FROM items WHERE items.order_id = orders.id) AS i —— 这在 PostgreSQL 直接报错，不是你写错了别名，是语法根本不允许。
- 必须显式加
LATERAL关键字，且只能出现在FROM子句中（JOIN右侧或紧跟FROM后） -
LATERAL子查询里所有对外层列的引用，必须带明确表别名，比如o.id，不能写orders.id（除非你给orders显式起了别名o） - 不支持在
WHERE或SELECT里直接用LATERAL；它不是函数修饰符，是FROM级的绑定机制
LEFT JOIN LATERAL 和 JOIN LATERAL 的行为差异
关键区别在于是否保留左表无匹配的行：
-
JOIN LATERAL等效于CROSS JOIN LATERAL：子查询返回 0 行时，该左表行被整行过滤掉（类似INNER JOIN） -
LEFT JOIN LATERAL：子查询返回 0 行时，仍保留左表行，右侧字段全为NULL
例如查每个用户最新订单，但要包含从未下单的用户：
SELECT u.user_id, o.order_amount, o.order_date FROM users u LEFT JOIN LATERAL ( SELECT amount AS order_amount, order_date FROM orders WHERE user_id = u.user_id ORDER BY order_date DESC LIMIT 1 ) o ON true;
如果这里写成 JOIN LATERAL，那些 u.user_id 在 orders 中没有记录的用户就彻底消失了。
什么时候不该用 LATERAL：性能陷阱与替代方案
LATERAL 不是银弹。每行左表数据都会触发一次子查询执行 —— 左表 10 万行，子查询就跑 10 万次。哪怕加了索引，也可能比提前聚合慢几倍。
- 子查询里用了未被索引的关联字段（如
items.order_id没建索引），会导致每次执行都全表扫描，放大 10 万倍 - 嵌套过深（
LATERAL里再套LATERAL）会让执行计划失控，建议拆成 CTE 或物化中间结果 - 若目标只是“每个部门平均工资”，用
GROUP BY+JOIN聚合更高效，而非对每个部门跑一遍子查询 - 若子查询逻辑固定、不依赖外层字段，直接改写为普通
JOIN或提前物化视图
典型实用场景：JSON 展开与时间区间展开
LATERAL 最不可替代的用途，是处理“一行变多行”的动态结构：
- 展开 JSONB 数组：
jsonb_array_elements(u.tags)必须配合LATERAL，否则无法绑定到u.tags - 展开时间区间：
generate_series(e.event_start, e.event_end, '1 day'::interval)需逐行计算起止，只能靠LATERAL
示例：把每个事件按天拆成多行
SELECT e.id, l.day::date AS event_day FROM events e CROSS JOIN LATERAL ( SELECT x::date AS day FROM generate_series(e.event_start, e.event_end, '1 day'::interval) AS x ) l;
注意这里用 CROSS JOIN LATERAL 是因为每个事件必然有至少一天（CHECK 约束保证 event_end >= event_start），不需要 LEFT。
最易被忽略的一点：LATERAL 子查询的执行顺序和物化时机由优化器决定，但它的语义强制“逐行绑定”——这意味着即使你加了 ORDER BY 和 LIMIT，也只对当前外层行生效，不会跨行去重或全局排序。
