LATERAL是PostgreSQL强制要求的关键字，用于使子查询能引用外层表字段；普通子查询因作用域隔离而禁止跨层引用，LATERAL则切换为每行执行一次的嵌套循环模型。
必须加 LATERAL 关键字，否则 ERROR: invalid reference to FROM-clause entry 会立刻报错——这不是写法问题，是 PostgreSQL 的语法硬性要求。
为什么普通子查询一引用外层字段就报错
普通子查询被优化器视为“独立快照”，执行前就固化为一次性结果集，根本看不到 FROM 左侧的表别名。你写的 (SELECT * FROM orders WHERE user_id = users.id) 不是字段名错了，而是 SQL 标准禁止这种跨作用域引用。
-
LATERAL不是语法糖，是切换执行模型的开关：它让子查询从“预计算一次”变成“对左表每行执行一次” - 漏写
LATERAL、写错位置（比如塞进WHERE或SELECT）、或外层没起别名（写users.id而不是u.id），都会触发这个错误 - 子查询必须用括号包裹，且
LATERAL必须紧贴左括号：LATERAL (SELECT ...)，不能写成JOIN LATERAL SELECT或FROM LATERAL (SELECT)
LEFT JOIN LATERAL 和 JOIN LATERAL 的行为区别
这不是风格选择，而是决定数据是否丢失的关键分界线。
-
JOIN LATERAL（等价于CROSS JOIN LATERAL）：子查询返回 0 行，该左表行直接丢弃，效果同INNER JOIN -
LEFT JOIN LATERAL：子查询返回 0 行，左表行仍保留，右侧所有字段为NULL - 必须显式写
ON true（或ON 1=1），漏掉会导致语义变成无条件CROSS JOIN LATERAL，结果爆炸
例如查用户 + 最新订单但要包含从未下单的用户，必须用 LEFT JOIN LATERAL；若误用 JOIN LATERAL，users 中那些没对应订单的记录就彻底消失。
LATERAL 子查询性能陷阱与索引要点
LATERAL 本质是 N 次子查询执行——左表 10 万行，子查询就跑 10 万次。优化器不会自动合并或重排，全靠你手动对齐。
- 子查询中的关联字段必须有复合索引，顺序严格匹配查询条件。例如子查询里是
WHERE o.user_id = u.id ORDER BY o.created_at DESC，索引必须建为orders(user_id, created_at)；如果只建了(created_at, user_id)，user_id条件无法高效跳查 - 避免在子查询
WHERE中用未索引字段过滤，比如AND status = 'paid'却没给status建索引，会导致每次全表扫描 - 别嵌套
LATERAL：外层返回多行，内层再逐行执行，中间结果可能指数级膨胀，建议拆成 CTE 或物化中间结果 - 别在子查询里加
OFFSET 0或其他无意义修饰，部分引擎（如旧版 BigQuery）会因此禁用LATERAL优化
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 的执行模型本身——它不是“更高级的 JOIN”，而是把 SQL 拉回嵌套循环范式。一旦左表行数失控或子查询没压住数据量，性能崩塌就是秒级的事。
