LATERAL 是 PostgreSQL 中子查询引用外层列的唯一合法方式，必须置于 FROM 子句中、紧贴子查询前，且外层列需带明确别名；其执行为逐行驱动，性能依赖索引与写法优化。
LATERAL 不是可选项，而是 PostgreSQL 中让子查询安全引用外层列的唯一合法方式。漏写它、位置不对、或别名不明确，99% 会直接报 ERROR: invalid reference to FROM-clause entry。
为什么 LATERAL 子查询总报“找不到表别名”？
根本原因不是字段写错了，而是普通子查询在 SQL 标准里被当作独立作用域处理——它压根看不到 FROM 左侧的表别名。
-
LATERAL关键字必须紧贴子查询括号前，不能写成JOIN LATERAL SELECT ...或FROM LATERAL (SELECT ...) - 外层列引用必须带明确别名，比如
u.id；写users.id（没给users起别名）必报错 - 子查询不能放在
WHERE或SELECT里——LATERAL只允许出现在FROM子句中，作为JOIN或逗号分隔的一部分
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表里id不在orders中的记录全没了
怎样避免 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返回多行，内层再LATERAL就指数级膨胀，建议拆成 CTE 或物化中间结果
哪些场景非用 LATERAL 不可？
不是所有子查询都适合改写。核心判断点是：逻辑是否需要逐行动态计算，且结果结构不可预知。
- 每行取 Top-N：如 “每个部门取工资最高的 2 名员工”，
ROW_NUMBER()会全表排序，LATERAL可按需拉取最多 2 行/组 - JSON 字段展开：
LATERAL jsonb_array_elements(data->'tags')是唯一能将单个 JSON 数组转为多行并绑定外层主键的方式 - 调用返回多列的函数：
LATERAL pg_stat_file('base/12345')必须用LATERAL才能拆解出各字段 - 避免重复子查询：SELECT 列表里多次出现相同
(SELECT COUNT(*) FROM ... WHERE x = t.id)，应提成LATERAL一次计算复用
LATERAL 的执行计划仍是“逐行驱动”的硬逻辑。它不参与连接重排，也不支持哈希或归并连接优化。一旦外层数据量突增，或子查询响应时间波动，整体耗时就会线性恶化——这不是 bug，是设计使然。 
