LATERAL JOIN 是子查询安全引用外层列的唯一合法方式，漏写 LATERAL、用错连接类型或索引不当会导致报错或结果丢失；它要求显式声明、括号包裹、别名明确，且仅支持特定数据库。
LATERAL JOIN 不是语法糖，而是让子查询能安全引用外层列的唯一合法方式；漏写 LATERAL 关键字、用错连接类型或没建对索引，都会导致报错或结果丢失。
为什么普通子查询一引用外层字段就报 ERROR: invalid reference to FROM-clause entry
因为 SQL 标准规定：非 LATERAL 子查询必须独立执行，优化器把它当“一次性快照”，根本不会把 users.id 这类左表字段暴露给右侧。你写 SELECT * FROM users, (SELECT * FROM orders WHERE user_id = users.id)，PostgreSQL 直接拒绝——不是别名写错了，是语法根本不允许。
必须显式加 LATERAL，且子查询里所有对外层列的引用都得带明确别名，比如 u.id，不能写 users.id（除非你给 users 起了别名 u）。
-
LATERAL只能在FROM子句中用，不能塞进WHERE或SELECT里 - 子查询必须用括号包裹：
LATERAL (SELECT ...)，不能写成JOIN LATERAL SELECT - MySQL 8.0+、PostgreSQL 9.3+、BigQuery、Trino 支持；SQLite 和 SQL Server 不支持
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)；如果只建了(created_at, user_id)，WHERE user_id = u.user_id就无法高效跳查 - 避免在子查询
WHERE中用未索引字段过滤，比如AND status = 'paid'却没给status建索引 - 别在子查询里加无意义的
OFFSET 0，部分引擎（如旧版 BigQuery）会因此禁用LATERAL优化 - 嵌套
LATERAL（比如外层LATERAL里再套一个）会让执行计划失控，建议拆成 CTE 或物化中间结果
什么时候不该硬上 LATERAL：性能陷阱与替代方案
LATERAL 不是银弹。它强制按外层顺序逐行执行，失去优化器的连接重排能力。
- 如果目标只是“每个部门平均工资”，用
GROUP BY+JOIN聚合更高效，而非对每个部门跑一遍子查询 - 若子查询逻辑固定、不依赖外层字段（比如只是查某张配置表），直接改用普通
JOIN或物化视图 - 当订单表巨大时，
LATERAL (SELECT ... LIMIT 3)比窗口函数ROW_NUMBER() OVER (PARTITION BY ...)快几十倍——但前提是索引对、条件下推到位；否则反而更慢 - JSON 数组展开、时间区间生成（如
generate_series）、调用返回多列的函数（如pg_stat_file）是LATERAL不可替代的场景
最容易被忽略的是：子查询里写的 WHERE 条件，必须和外层列绑定紧密，且所有过滤字段都要进索引；否则你以为在优化，其实每行都在全表扫。
