PostgreSQL中普通子查询在JOIN中不能引用左表字段，因SQL标准要求非LATERAL子查询独立执行、无法感知外部作用域；LATERAL子查询则显式支持逐行绑定，需在FROM子句中用LATERAL关键字声明，并可引用左侧已定义表。
为什么普通子查询在JOIN中不能引用左表字段
PostgreSQL在标准JOIN中禁止子查询直接引用左表（如FROM orders）的列，比如写SELECT * FROM orders JOIN (SELECT * FROM items WHERE items.order_id = orders.id) AS i ON true会报错ERROR: invalid reference to FROM-clause entry for table "orders"。这不是语法疏漏，而是SQL标准限制：非LATERAL子查询必须独立执行，无法感知外部作用域。
根本原因是子查询被当作“一次性预计算”看待，优化器无法建立左表行与子查询之间的逐行绑定关系。LATERAL就是为打破这个限制而设计的——它显式声明“该子查询需对左表每一行重新执行一次”。
LATERAL的正确写法和必要条件
必须用LATERAL关键字显式标记子查询，并且只能出现在FROM子句中（JOIN右侧或FROM后直接跟）。关键规则：LATERAL子查询里可以安全引用其左侧所有已定义的表别名，但不能引用右侧后续表。
-
LATERAL必须紧贴子查询前，不能省略（哪怕只有一行） - 子查询若返回多行，效果等同于
CROSS JOIN；若返回0行，则该左表行被过滤掉（类似INNER JOIN） - 支持在
LEFT JOIN LATERAL中保留左表空匹配（此时子查询返回NULL）
典型写法：
SELECT o.id, i.name, i.price FROM orders o LEFT JOIN LATERAL ( SELECT name, price FROM items WHERE items.order_id = o.id ORDER BY created_at DESC LIMIT 1 ) i ON true;
常见误用场景和坑点
最容易踩的是把LATERAL当成万能胶水，忽略性能代价。每次左表一行都会触发一次子查询执行，如果左表有10万行，子查询就运行10万次——即使加了索引，也可能比提前聚合慢几倍。
- 误在WHERE中写
LATERAL：LATERAL只允许在FROM子句，WHERE (SELECT ...) = x这种写法永远不支持LATERAL - 混淆LEFT JOIN LATERAL和JOIN LATERAL：前者保留左表空结果，后者会丢弃无匹配的左表行
- 子查询里用了未被索引的关联字段（如
items.order_id没建索引），导致全表扫描放大10万倍 - 嵌套过深：LATERAL里再套LATERAL容易让执行计划失控，建议拆成CTE或物化中间结果
替代方案对比：什么时候不该用LATERAL
如果子查询逻辑固定、不依赖左表具体值（比如查全局配置表），直接用普通JOIN更高效；如果需要对左表每行做聚合计算（如统计每个订单的item数量），优先考虑GROUP BY + 聚合函数，而不是LATERAL (SELECT COUNT(*) ...)。
真正适合LATERAL的场景很明确：需要基于左表某行的动态条件，实时查询另一张表的**单条/少量记录**，且该查询无法提前聚合（例如取最新一条日志、按权重随机选一个关联项、调用返回集的函数json_to_recordset()）。
复杂点在于：LATERAL本身不解决数据倾斜，如果某个order_id对应上万条items，子查询里的LIMIT 1仍要扫描全部——这时候得靠索引覆盖+排序字段联合索引兜底。
