LATERAL 是 PostgreSQL 中实现每行驱动子查询的关键特性，支持 UNNEST 动态关联展开数组或 JSON 字段，显式使用可提升可读性、可控性及性能；需避免全表扫描、大数组未截断等陷阱，并合理选用 jsonb_path_query 或自定义函数替代。
LATERAL 是 PostgreSQL 中实现“每行驱动子查询”的关键特性，常配合 UNNEST 对数组或 JSON 字段做多行展开。它不是简单地“把数组炸开”，而是让子查询能引用外部表的列，从而支持动态、关联式的展开逻辑。用对了，性能和可读性都提升；用错了，可能触发嵌套循环+全量 unnest，导致慢得离谱。
为什么 UNNEST 需要 LATERAL？
UNNEST 本身是集合返回函数（SRF），直接写在 SELECT 列表里会隐式转为 LATERAL（PostgreSQL 10+），但显式写出 LATERAL 更清晰、更可控。更重要的是：当展开逻辑依赖外层字段时（比如按用户 ID 查其权限列表、按订单 ID 解析商品明细），必须用 LATERAL 才能传递上下文。
反例：
SELECT id, UNNEST(tags) FROM posts; —— 可行，但无法过滤或关联其他表
SELECT id, t.tag FROM posts, UNNEST(tags) AS t(tag); —— 旧写法，等价于 CROSS JOIN，语义模糊且不可控
正解：
SELECT p.id, t.tag
FROM posts p
LATERAL UNNEST(p.tags) AS t(tag);
常见性能陷阱与优化要点
LATERAL + UNNEST 的慢，往往不是函数本身慢，而是执行计划失控。以下是高频问题和对应解法：
-
避免在 LATERAL 内部做全表扫描：比如
LATERAL (SELECT * FROM logs WHERE logs.user_id = u.id ORDER BY ts DESC LIMIT 5)，若 users 表有 10 万行，就可能触发 10 万次索引扫描。应确保logs(user_id, ts)有联合索引，并确认执行计划中用了 Index Scan + Limit，而非 Seq Scan -
UNNEST 大数组前先截断：单个字段存了上千个元素（如日志标签、埋点事件）时，UNNEST 后生成海量中间行。可在 LATERAL 前加条件过滤或限制长度：
LATERAL UNNEST(ARRAY(SELECT elem FROM UNNEST(p.tags) elem LIMIT 100)) -
用 JOIN 替代冗余 LATERAL：如果只是静态展开（如固定映射表），用
JOIN ... ON true或CROSS JOIN更轻量；LATERAL 应用于“每行不同展开逻辑”的场景
JSONB 数组展开的典型优化写法
处理 jsonb 类型的数组字段（如 details::jsonb → 'items'）时，常需解析并关联其他表。错误写法会导致多次 JSON 解析或丢失索引能力：
- ❌
LATERAL jsonb_array_elements(details->'items') AS i—— 每次调用都重新解析整个 JSONB，无索引支持 - ✅ 预提取 + LATERAL：
SELECT o.id, i.item_name, i.qty
FROM orders o
CROSS JOIN LATERAL (
SELECT value->>'name' AS item_name,
CAST(value->>'qty' AS int) AS qty
FROM jsonb_array_elements(o.details->'items') AS value
) AS i
WHERE i.qty > 0;
这样可结合表达式索引（如CREATE INDEX idx_orders_items_qty ON orders ((details#>>'{items,0,qty}'))）加速预过滤
替代方案对比：UNNEST vs jsonb_path_query vs 自定义函数
面对复杂展开需求，不必死守 UNNEST：
- jsonb_path_query()：适合带条件的 JSON 路径查询（如 “所有 price > 100 的 item”），支持路径过滤，减少中间行数
- 自定义 SRF 函数：当展开逻辑含业务规则（如“跳过已下架商品”“合并重复 SKU”），封装成函数 + VOLATILE/STABLE 注解，便于复用和执行计划优化
- MATERIALIZED CTE（WITH）：若展开结果会被多次引用，先用 WITH 把 LATERAL 结果物化，避免重复计算
