LATERAL子查询是PostgreSQL中唯一能安全引用外层列的机制；普通子查询因作用域隔离无法访问FROM左侧表别名，必须用LATERAL并配合正确索引、LEFT JOIN等避免性能与语义错误。
LATERAL子查询不是“语法糖”，而是 PostgreSQL 中唯一能安全、合法让子查询引用外层列的机制；不用它，相关子查询容易退化为 N×M 嵌套扫描，一不小心就从毫秒变分钟。
为什么普通子查询总报 invalid reference to FROM-clause entry
错误不是因为你字段写错了，而是 SQL 标准规定：普通子查询是独立作用域，根本看不到 FROM 左侧的表别名。比如 (SELECT * FROM orders WHERE user_id = users.id) 里 users.id 就非法——users 这个别名在子查询里不可见。
- 必须加
LATERAL关键字，且紧贴子查询括号前，不能写成JOIN LATERAL SELECT或FROM LATERAL (SELECT) - 外层列引用必须带明确别名，如
u.id；写users.id（没给users起别名）必报错 -
LATERAL只允许出现在FROM子句中，不能塞进WHERE或SELECT里
LEFT JOIN LATERAL 和 JOIN LATERAL 的行为差异极大
这不是风格问题，直接决定结果是否丢数据。
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
-
JOIN LATERAL（等价于CROSS JOIN LATERAL）：子查询返回空，该外层行直接消失，类似INNER JOIN -
LEFT JOIN LATERAL：子查询返回空，外层行仍保留，右侧所有字段为NULL - 查“用户 + 最新订单”但要包含从未下单的用户？必须用
LEFT JOIN LATERAL，否则users表里没对应订单的记录全没了
怎样避免 LATERAL 变成性能黑洞
LATERAL 本质是 N 次子查询执行。左表 10 万行，子查询就真跑 10 万次。优化器不会帮你合并或重排——索引和写法必须手动对齐。
- 确保子查询中用于关联的字段（如
orders.user_id）落在**复合索引最左前缀**上。例如WHERE user_id = u.id AND created_at >= $1，必须建INDEX ON orders(user_id, created_at)；只建(created_at, user_id)就无法高效跳查 - 避免在子查询
WHERE中使用未索引字段过滤，比如AND status = 'active'却没给status建索引，会导致每次扫描放大 - 不要嵌套
LATERAL：外层返回多行，内层再LATERAL就指数级膨胀；建议拆成WITH或物化中间结果 - 用
EXPLAIN看执行计划：如果看到大量Index Scan或Seq Scan嵌套在Lateral节点下，且Actual Rows远超预期，说明没走对索引
哪些场景非用 LATERAL 不可
核心判断点是：逻辑是否需要逐行动态计算，且结果结构不可预知。
- 每行取 Top-N：如 “每个部门取工资最高的 2 名员工”，
ROW_NUMBER()会全表排序，LATERAL可按需拉取最多 2 行/组 - JSON 字段展开：
LATERAL jsonb_array_elements(data->'tags')是唯一能将单个 JSON 数组转为多行并绑定外层主键的方式 - 调用返回多列的函数：
LATERAL pg_stat_file('base/12345')必须用LATERAL才能拆解字段 - 替换标量子查询：
(SELECT amount FROM orders ... LIMIT 1)改成LEFT JOIN LATERAL (SELECT ...) ON true，既保 NULL 行，又避免重复解析
最容易被忽略的是：LATERAL 子查询里的表别名不能和外层同名，否则报 table name "xxx" specified more than once；还有，ON true 不能省，否则语法报错。
