LATERAL JOIN是PostgreSQL中唯一合法让子查询引用外层列的方式；必须显式声明、用LEFT JOIN LATERAL保留无匹配行、建对复合索引（如orders(user_id, created_at)），否则报ERROR或丢数据。
LATERAL JOIN 不是“实现侧向关联”的可选项，而是 PostgreSQL 中唯一合法让子查询引用外层列的方式；漏写 LATERAL、用错连接类型或索引缺失，直接导致报错或结果丢行。
为什么 SELECT * FROM users, (SELECT * FROM orders WHERE user_id = users.id) 一定报错
这不是别名写错了，也不是字段名打错了——PostgreSQL 明确禁止非 LATERAL 子查询引用 FROM 左侧的表字段。错误信息通常是：ERROR: invalid reference to FROM-clause entry。因为标准 SQL 要求子查询必须独立执行，优化器把它当“快照”，根本不会把 users.id 暴露给右边。
- 必须显式加
LATERAL关键字，且紧贴子查询括号前：LATERAL (SELECT ...) - 外层列引用必须带明确别名，比如
u.id；写users.id（没给users起别名）必报错 -
LATERAL只能在FROM或JOIN子句中出现，不能塞进WHERE或SELECT里
LEFT JOIN LATERAL 和 JOIN LATERAL 的区别不是风格，是数据存亡线
前者保留左表所有行（子查询无结果时右侧全为 NULL），后者等价于 CROSS JOIN LATERAL，子查询返回空就直接删掉该左表行。
- 查“每个用户最新订单，但要包含从未下单的用户”：必须用
LEFT JOIN LATERAL，否则users表里没订单的记录就彻底消失 - 必须写
ON true（或ON 1=1）；漏掉会变成无条件CROSS JOIN LATERAL，语义全乱 - 别在子查询里写
ON o.user_id = u.id——子查询内部已用WHERE关联，再加ON条件会重复约束甚至报错
性能崩盘最常见原因：索引没对上顺序
LATERAL 本质是 N 次子查询执行。左表 10 万行，子查询就跑 10 万次。哪怕每次 1ms，总耗时也接近 100 秒。
- 复合索引字段顺序必须匹配子查询
WHERE+ORDER BY：例如子查询是WHERE user_id = u.id ORDER BY created_at DESC LIMIT 1，索引就得建为orders(user_id, created_at) - 如果只建了
(created_at, user_id)，WHERE user_id = u.id就无法高效跳查，退化为全表扫描 - 避免在子查询
WHERE中用未索引字段过滤，比如AND status = 'paid'却没给status建索引，单次扫描代价会被放大 10 万倍
JSON 数组展开必须配 LATERAL，但 UNNEST 写法极易踩坑
像 jsonb_array_elements() 这类集合返回函数（SRF）本身不感知外层上下文。直接写在 SELECT 列表里虽能隐式触发 LATERAL（PG 10+），但语义模糊、无法前置过滤，还可能被优化器误判。
- 正确写法：
FROM users u LEFT JOIN LATERAL jsonb_array_elements(u.tags) AS t(tag) ON true - 错误写法：
SELECT u.name, jsonb_array_elements(u.tags) FROM users u——看似能跑，但无法加WHERE过滤 tag，也难控制别名和 NULL 处理 - 嵌套
LATERAL（比如 A →LATERALB →LATERALC）会让执行计划指数级膨胀，优先拆成 CTE 或物化中间结果
真正容易被忽略的是：LATERAL 不是语法糖，它是逐行绑定的硬性机制；你写的每一条 LATERAL 子查询，都在数据库里真实地、独立地执行了一次——索引对不对、连接类型选没选对、有没有隐式触发，全都直接影响结果是否完整、性能是否可控。
