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，有几个关键点必须抓住。首先，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只允许出现在FROM子句。像WHERE (SELECT ...) = x这种写法，是永远不支持LATERAL的。 - 混淆连接类型：
LEFT JOIN LATERAL会保留左表的所有行，而普通的JOIN LATERAL（即INNER JOIN LATERAL）则会丢弃那些在子查询中没有匹配结果的左表行。 - 缺失关键索引：如果子查询中用来关联左表的字段（比如
items.order_id）没有建立索引，那么每一次子查询执行都可能引发一次全表扫描，10万行就是10万次全表扫描，性能灾难可想而知。 - 过度嵌套：在
LATERAL子查询里再嵌套一个LATERAL，很容易让查询执行计划变得复杂且难以控制。遇到这种情况，更稳妥的做法是拆分成公共表表达式（CTE）或者将中间结果物化。
替代方案对比：什么时候不该用LATERAL
那么，什么时候应该对LATERAL说“不”呢？如果子查询的逻辑是固定的、完全不依赖于左表的具体值（例如查询一个全局配置表），那么直接使用普通JOIN通常会更加高效。同样，如果业务需求是对左表的每一行进行聚合计算（比如统计每个订单包含的商品数量），优先考虑使用GROUP BY配合聚合函数（如COUNT(*)），而不是写成LATERAL (SELECT COUNT(*) ...)。
事实上，LATERAL真正大放异彩的场景非常明确：那就是需要基于左表某一行的动态条件，去实时查询另一张表的**单条或少量记录**，并且这个查询逻辑无法通过提前聚合来完成。典型的例子包括：获取最新的一条日志记录、根据权重随机选取一个关联项、或者调用一个返回结果集的函数（如json_to_recordset()）。
最后还有一个复杂的点：LATERAL本身并不解决数据倾斜问题。假设某个order_id对应着上万条items记录，即使子查询里写了LIMIT 1ORDER BY created_at DESC）的那“一条”，可能仍然需要扫描该订单下的所有商品记录。这时候，性能的保障就落在了索引上——往往需要建立覆盖索引或者包含排序字段的联合索引来兜底。
