LATERAL 是 PostgreSQL 中为左表每行独立执行子查询的唯一合规写法，解决非 LATERAL 子查询无法引用外层字段的问题；其使用需严格遵循作用域、索引与连接类型规则，否则引发性能灾难或数据丢失。
PostgreSQL 中 LATERAL 不是用来“解决难题”的工具，而是当你明确需要「为左表每一行独立执行一次子查询」时的唯一合规写法。它不是补丁，是设计使然——用错场景或忽略约束，反而会放大性能问题。
为什么普通 JOIN 里不能直接引用左表字段
比如写 SELECT * FROM orders o JOIN (SELECT * FROM items WHERE order_id = o.id) i ON true，PostgreSQL 会报错：ERROR: invalid reference to FROM-clause entry for table "o"。这不是 bug，是 SQL 标准强制要求：非 LATERAL 子查询必须“一次性预计算”，不能依赖外层行值。优化器无法建立逐行绑定关系，所以直接禁止。
你真正要的不是“绕过限制”，而是告诉优化器：“这个子查询必须按左表顺序，一行一行跑”。LATERAL 就是那个开关。
-
LATERAL只能出现在FROM或JOIN子句中，不能放在WHERE或SELECT里 - 子查询中可安全引用其左侧所有已声明的表别名（如
o.id），但不能引用右侧后续表 - 必须显式写
LATERAL关键字，不能省略；也不能靠空格或换行“隐式生效”
LEFT JOIN LATERAL 和 JOIN LATERAL 的行为差异
区别只在空结果处理上，但影响极大：
-
JOIN LATERAL：子查询返回 0 行 → 左表该行被丢弃（类似INNER JOIN） -
LEFT JOIN LATERAL：子查询返回 0 行 → 左表该行保留，右侧字段全为NULL
例如查每个用户最新订单，但有些用户还没下单：
SELECT u.name, latest_order.amount FROM users u LEFT JOIN LATERAL ( SELECT amount FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1 ) latest_order ON true;
如果这里误写成 JOIN LATERAL，那些没下单的用户就彻底消失了——不是数据丢了，是你主动过滤掉了。
性能陷阱：LATERAL 不是银弹，索引才是关键
LATERAL 本质是 N 次子查询执行。左表 10 万行，子查询就跑 10 万次。哪怕每次毫秒级，总耗时也可能到分钟级。
- 确保子查询中的关联字段有索引，例如
orders(user_id, created_at)复合索引（注意顺序） - 避免在
LATERAL子查询里用未索引字段做WHERE条件，否则单次扫描变全表扫描，10 万倍放大 - 嵌套
LATERAL（比如 A → LATERAL B → LATERAL C）会让执行计划迅速失控，优先拆成 CTE 或物化中间结果 - 如果只是固定两表关联（无动态排序、无 JSON 展开、无函数调用），老老实实用
INNER JOIN，优化器能重排连接顺序，LATERAL反而锁死执行路径
常见真实场景怎么写才不翻车
三个高频用例，直接对应你查日志、展 JSON、调函数时的实际需求：
- 查每个用户的最近一条订单：
LATERAL (SELECT * FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1)—— 必须带ORDER BY + LIMIT，否则可能返回任意一条 - 展开 JSONB 数组字段：
LATERAL jsonb_array_elements(data->'tags') AS tag—— 注意函数返回的是 setof record，必须用LATERAL才能拆成多行 - 调用返回多列的系统函数：
LATERAL pg_stat_file('base/12345')—— 普通SELECT pg_stat_file(...)只能当表达式用，要取其中的size或mtime字段，必须走LATERAL
最易被忽略的一点：所有这些子查询里的字段引用，都必须基于左侧已声明的别名（如 u.id），不能跳过别名直接写表名（users.id），否则依然报 invalid reference。别名不是可选语法糖，是作用域锚点。
