lateral是postgresql中让子查询引用外层列的唯一合法方式；普通子查询被优化器视为独立快照，无法访问from左侧字段，必须显式声明lateral、使用表别名（如u.id）并在from子句中书写，否则报error: invalid reference to from-clause entry。
为什么普通子查询一引用外层字段就报 ERROR: invalid reference to FROM-clause entry
因为标准 SQL 要求非 LATERAL 子查询必须独立执行，优化器把它当“一次性预计算”，根本不会把 users.id 这类左表字段暴露给右侧。你写 SELECT * FROM users, (SELECT * FROM orders WHERE user_id = users.id)，PostgreSQL 直接拒绝——不是别名没起对，是语法根本不允许。
必须显式加 LATERAL，且只在 FROM 子句中生效；子查询里所有对外层列的引用，必须带明确别名（如 u.id），不能直接用原表名 users.id。
LEFT JOIN LATERAL 和 JOIN LATERAL 的行为差异在哪
关键看是否保留左表无匹配的行：
-
JOIN LATERAL（等效CROSS JOIN LATERAL）：子查询返回 0 行，该左表行被整行丢弃，类似INNER JOIN -
LEFT JOIN LATERAL：子查询返回 0 行，左表行仍保留，右侧字段全为NULL
例如查每个用户最新订单但要包含从未下单的用户，必须写：
SELECT u.user_id, o.order_amount FROM users u LEFT JOIN LATERAL ( SELECT amount AS order_amount FROM orders WHERE user_id = u.user_id ORDER BY created_at DESC LIMIT 1 ) o ON true;
漏掉 LEFT 或误写成 ON o.user_id = u.user_id（子查询里已用 WHERE 关联，这里重复会出错）都会破坏语义。
子查询里带 LIMIT 时，索引怎么建才不拖慢 10 万行查询
LATERAL 本质是 N 次子查询执行。左表 10 万行，子查询就跑 10 万次。哪怕每次 1ms，总耗时也接近 100 秒。
必须让每次子查询能走索引，否则就是 10 万次全表扫描：
- 关联字段必须有索引，比如
orders(user_id, created_at)复合索引（顺序不能反：先user_id再created_at） - 避免在子查询
WHERE中用未索引字段过滤（如status = 'paid'却没给status建索引） - 别在子查询里加无意义的
OFFSET 0，部分引擎（如旧版 BigQuery）会因此禁用LATERAL优化
如果子查询逻辑固定、不依赖外层字段（比如只是查某张配置表），直接改用普通 JOIN 或物化视图更高效。
JSON 数组展开或时间区间生成必须用 LATERAL 吗
是的，这是 LATERAL 不可替代的场景。比如主表 users 有个 tags JSONB 字段存了数组，想把每个 tag 拆成一行并关联原始记录：
SELECT u.name, tag->>'name' AS tag_name FROM users u, LATERAL jsonb_array_elements(u.tags) AS tag;
这里 jsonb_array_elements() 是表函数，必须配合 LATERAL 才能访问 u.tags；普通子查询无法传入外层字段值，也没法把一个数组“展开”成多行结果集。
同理，用 generate_series() 拆分时间区间、或嵌套调用自定义返回集合的函数，都绕不开 LATERAL —— 它不是语法糖，是让 SQL 具备行级动态能力的底层机制。
