LATERAL 是 PostgreSQL 中引用外层表字段的必需关键字，普通子查询因作用域隔离无法访问外层列；LEFT JOIN LATERAL 保留无匹配的外层行，JOIN LATERAL 则丢弃；必须配合 ON TRUE、正确索引及避免嵌套以确保逻辑正确与性能。
必须加 LATERAL 关键字，否则 ERROR: invalid reference to FROM-clause entry 会立刻报错——这不是写法问题，而是 PostgreSQL 的语法硬性要求。
为什么普通子查询引用外层表总会失败
普通子查询在 SQL 标准里被当作独立作用域处理，优化器会把它当成一次性预计算结果，根本看不到 orders.id 这类左表字段。哪怕你写了 WHERE items.order_id = orders.id，PostgreSQL 也会直接拒绝，不是别名写错，是语法根本不允许。
-
LATERAL必须紧贴子查询括号前：LATERAL (SELECT ...)，不能写成JOIN LATERAL SELECT或FROM LATERAL (SELECT) - 外层列引用必须带明确别名，比如
o.id；写orders.id（没给orders起别名）必报错 -
LATERAL只能在FROM子句中用，不能塞进WHERE或SELECT里
LEFT JOIN LATERAL 和 JOIN LATERAL 的行为区别
这不是风格选择，而是决定结果集是否丢数据的关键分界线。
-
JOIN LATERAL（等价于CROSS JOIN LATERAL）：子查询返回 0 行，该外层行直接消失，效果类似INNER JOIN -
LEFT JOIN LATERAL：子查询返回 0 行，外层行仍保留，右侧所有字段为NULL - 典型场景如“查用户 + 最新订单，但要包含从未下单的用户”，必须用
LEFT JOIN LATERAL，否则users表里没对应订单的记录就全没了 - 记得写
ON TRUE（或ON 1=1），漏掉会导致变成无条件CROSS JOIN LATERAL，语义全乱
性能陷阱：索引不匹配会让 LATERAL 变慢十倍
LATERAL 本质是 N 次子查询执行——左表 10 万行，子查询就跑 10 万次。优化器不会自动合并或重排，全靠你手动对齐索引和写法。
- 子查询中的关联字段必须有复合索引，顺序要匹配查询条件，例如
orders(user_id, created_at)；如果只建了(created_at, user_id)，WHERE user_id = u.id就无法高效跳查 - 避免在子查询
WHERE中用未索引字段过滤，比如AND status = 'active'却没给status建索引，每次都会放大扫描范围 - 别嵌套
LATERAL：外层返回多行，内层再LATERAL就指数级膨胀，建议拆成CTE或物化中间结果
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或嵌套子查询 - 大数组风险：单行含上千元素会瞬间生成海量中间行，应提前限制，比如
LATERAL UNNEST(ARRAY(SELECT elem FROM UNNEST(p.tags) elem LIMIT 100))
最易被忽略的是索引顺序和 ON TRUE 的强制存在——没这两项，LATERAL 不是慢，而是逻辑错。
