lateral是postgresql中允许子查询引用左侧表列的特性，与普通子查询（无法访问外部字段）本质区别在于执行时机：lateral按外层每行逐行求值，支持动态关联、0-n行返回及left join lateral语义，需显式声明且依赖索引优化。
什么是LATERAL，它和普通子查询的区别在哪
LATERAL 允许子查询引用左侧表的列，而普通子查询在 FROM 子句中不能直接访问外部查询的字段。如果你写 SELECT * FROM orders, (SELECT * FROM items WHERE items.order_id = orders.id) AS sub，PostgreSQL 会报错：ERROR: invalid reference to FROM-clause entry for table "orders" —— 因为非 LATERAL 子查询在逻辑上先于外层执行。
加了 LATERAL 就行：子查询按每行“逐行求值”，类似嵌套循环。它不是性能优化工具，而是语义必需：没有它，某些动态关联根本写不出来。
- 必须显式写
LATERAL关键字（PostgreSQL 9.3+） -
LATERAL子查询可以返回 0 行、1 行或多行，行为上接近JOIN的右端 - 如果子查询返回 0 行，该外层行仍保留（配合
LEFT JOIN LATERAL实现“左连接中的动态过滤”）
LEFT JOIN LATERAL 的正确写法和常见错误
想对每个订单取其最新一条支付记录，且保留没支付过的订单 —— 这是典型场景。错误写法是用 LEFT JOIN ... ON ... WHERE ... 把过滤条件塞进 ON 或 WHERE，结果要么漏掉空支付的订单，要么误过滤。
正确结构是：LEFT JOIN LATERAL (子查询) ON TRUE，或更简洁地省略 ON（因为 LATERAL 本身不依赖等值条件）：
SELECT o.id, o.amount, p.status, p.created_at FROM orders o LEFT JOIN LATERAL ( SELECT status, created_at FROM payments WHERE payments.order_id = o.id ORDER BY created_at DESC LIMIT 1 ) p ON TRUE;
- 别写成
LEFT JOIN LATERAL (...) p ON p.order_id = o.id—— 子查询里已通过WHERE关联，再在ON里重复会导致逻辑冗余甚至错误 - 别漏掉
ON TRUE或等效条件；否则 PostgreSQL 会当作 CROSS JOIN LATERAL（即无条件连接），破坏“左”的语义 - 子查询中不能出现未定义别名，比如写
WHERE payments.order_id = o.id没问题，但写WHERE p.order_id = o.id会报错 ——p是外层别名，子查询里不可见
LATERAL 子查询里的 LIMIT 和 ORDER BY 怎么影响结果
LIMIT 在 LATERAL 中不是“限制总行数”，而是对每一行外层记录独立生效。比如外层有 100 个订单，子查询带 LIMIT 1，最多返回 100 行（每个订单至多 1 条支付）。
但要注意：如果没有 ORDER BY，LIMIT 1 返回的是任意一条，不可预测。业务上要“最新支付”，就必须写 ORDER BY created_at DESC。
-
ORDER BY必须作用于子查询内部字段，不能引用外层别名（如ORDER BY o.created_at在子查询里非法） - 若需按多个条件排序，例如“优先选成功支付，再按时间倒序”，写
ORDER BY (status = 'success') DESC, created_at DESC - 子查询中使用窗口函数（如
ROW_NUMBER() OVER (...)）也能实现类似效果，但通常比ORDER BY + LIMIT更重，且无法利用索引加速
性能和索引注意事项
LATERAL 本质是“对左表每行执行一次子查询”，所以性能高度依赖子查询是否能走索引。如果子查询里有 WHERE payments.order_id = o.id，就要确保 payments(order_id) 或 payments(order_id, created_at) 有复合索引。
- 推荐建索引：
CREATE INDEX idx_payments_order_created ON payments (order_id, created_at DESC); - 避免在 LATERAL 子查询中写
WHERE order_id = o.id AND status IN ('paid', 'refunded')却没把status加进索引 —— 可能导致索引失效，退化为 per-row filter - EXPLAIN ANALYZE 时注意看子查询是否显示
Index Scan using ...；如果出现Seq Scan on payments，基本说明索引没被用上 - 当左表很大（比如千万级 orders），而子查询又慢，考虑是否真需要 LATERAL —— 有时改用聚合子查询（
SELECT ... FROM orders o LEFT JOIN (SELECT order_id, MAX(created_at) ... GROUP BY order_id) p ...）反而更快
最易被忽略的一点：LATERAL 不自动去重，也不保证顺序。即使你只想要“一个最新记录”，也得靠 ORDER BY + LIMIT 1 显式控制；靠直觉认为“子查询自然返回第一条”是危险的。
