LATERAL子查询是PostgreSQL中唯一合法引用外层列的方式，必须显式声明、位置正确、别名明确；LEFT JOIN LATERAL保留无匹配行，JOIN LATERAL则丢弃；JSON展开和动态过滤等场景必需使用，但需警惕性能陷阱。
LATERAL子查询不是语法糖，它是PostgreSQL中让子查询引用外层列的唯一合法方式；漏写LATERAL或误用别名，99%会直接报ERROR: invalid reference to FROM-clause entry。
为什么LATERAL子查询里引用users.id总报错
普通子查询在执行前被优化器视为“独立快照”，根本看不到FROM左侧的表别名。你写的(SELECT * FROM orders WHERE user_id = users.id)之所以失败，不是字段名错了，而是SQL标准禁止这种跨作用域引用。
- 必须显式加
LATERAL关键字，且紧贴子查询括号前：LATERAL (SELECT ...)，不能写成JOIN LATERAL SELECT或FROM ... LATERAL SELECT - 外层列必须带明确表别名，比如
u.id；写users.id会报错，除非你给users起了别名u -
LATERAL只能出现在FROM子句中（逗号后或JOIN右侧），不能放在WHERE或SELECT里
LEFT JOIN LATERAL和JOIN LATERAL行为差异极大
区别不在语法，而在结果集是否保留左表无匹配的行：
-
JOIN LATERAL（等价于CROSS JOIN LATERAL）：子查询返回0行，该左表行直接丢弃，类似INNER JOIN -
LEFT JOIN LATERAL：子查询返回0行，左表行仍保留，右侧所有字段为NULL
例如查每个用户的最新订单但要包含从未下单的用户，必须用LEFT JOIN LATERAL，否则users中id不在orders里的记录全消失：
SELECT u.name, latest_order.amount FROM users u LEFT JOIN LATERAL ( SELECT amount FROM orders o WHERE o.user_id = u.id ORDER BY o.order_time DESC LIMIT 1 ) AS latest_order ON true;
JSON数组展开必须配LATERAL，但UNNEST位置很关键
jsonb_array_elements()这类集合返回函数（SRF）本身不感知外层上下文，直接写在SELECT列表里虽能隐式触发LATERAL（PG 10+），但语义模糊、不可控，且无法做前置过滤。
- 错误写法：
SELECT id, UNNEST(tags) FROM posts——无法关联其他表，也无法按条件截断大数组 - 正确写法：
SELECT p.id, t.tag FROM posts p LATERAL UNNEST(p.tags) AS t(tag)——明确绑定p.tags，后续可加WHERE或嵌套子查询 - 大数组风险：
UNNEST(p.tags)若单行含上千元素，会瞬间生成海量中间行；应提前限制：LATERAL UNNEST(ARRAY(SELECT elem FROM UNNEST(p.tags) elem LIMIT 100))
性能陷阱：每行触发一次子查询，索引失效比想象中更常见
LATERAL本质是嵌套循环：左表N行，子查询就执行N次。哪怕加了索引，也可能因写法不当退化为全表扫描。
- 子查询中
WHERE条件字段未建联合索引（如orders(user_id, order_time)），ORDER BY ... LIMIT 1就会变成Seq Scan - 在
LATERAL内部调用jsonb_path_query()或反复解析同一JSON字段，会重复计算；应先用CTE或子查询预提取结构化字段 - 嵌套
LATERAL（比如LATERAL (...) LATERAL (...)）会让执行计划失控，优先拆成两个CTE或物化中间结果
最易被忽略的一点：LATERAL强制按外层顺序执行，优化器无法重排连接顺序。如果只是固定两表关联，INNER JOIN通常更快；LATERAL只应在“逐行动态逻辑”不可替代时使用。
