lateral join 是处理 jsonb 数组唯一可控方式；逗号连接等价于 cross join 会导致 null/空数组行丢失，须用 left join lateral + coalesce 保行；多层展开需防笛卡尔积，应分步过滤；lateral 是执行模型切换，性能随数组长度和嵌套深度陡降。
LATERAL JOIN 是处理数组（尤其是 JSONB 数组）唯一可控的方式；直接在 SELECT 里用 jsonb_array_elements() 虽能运行，但无法过滤、无法关联、结果不可预测。
为什么必须显式写 LATERAL 而不是逗号连接
常见错误是写成 SELECT id, elem FROM orders, jsonb_array_elements(items) AS elem——这等价于 CROSS JOIN，不绑定外层行上下文。一旦 items 是 NULL 或空数组 []，该订单行就彻底消失，且你根本没法在 WHERE 里加条件去拦。
-
LATERAL显式声明“这一行驱动一次函数调用”，语义清晰、可调试 - 外层列引用必须带别名：写
o.items，不能写orders.items（除非你给orders起了别名o） - 字段类型是
json而非jsonb？必须先强转：o.items::jsonb
如何保留原行（避免 NULL/空数组导致丢数据）
jsonb_array_elements() 遇到 NULL 或 [] 时返回零行，LATERAL 关联下即丢外层行——这不是 bug，是设计行为。线上数据常含这类值，查着查着行数就变少了。
- 用
LEFT JOIN LATERAL替代JOIN LATERAL，确保无数组的订单仍保留 - 配合
COALESCE补默认空数组：LATERAL jsonb_array_elements(COALESCE(o.items, '[]'::jsonb)) - 若需严格过滤，用
WHERE o.items IS NOT NULL AND JSONB_ARRAY_LENGTH(o.items) > 0（别用o.items != '[]'，JSONB 比较规则特殊）
多层嵌套数组展开时防笛卡尔积爆炸
比如结构是 {"users": [{"id":1,"tags":["a","b"]}, {"id":2,"tags":["c"]} ]}，想展开成「用户 × 标签」二维关系。错误写法是两层 LATERAL 直接嵌套：
FROM orders o LATERAL jsonb_array_elements(o.data->'users') AS u LATERAL jsonb_array_elements(u.value->'tags')
若某用户有 100 个 tag，10 个用户就会生成 1000 行，中间没剪枝，执行计划极易失控。
- 先用
LATERAL展开第一层，存为 CTE 或子查询 - 第二层再基于已过滤后的中间结果展开，避免原始数据量放大
- 必要时加
WHERE提前筛掉无效u.value->'tags'，比如u.value ? 'tags'
最易被忽略的是：LATERAL 不是语法糖，它是执行模型的切换——每行左表数据触发一次子查询执行。数组越长、外层行越多、嵌套越深，性能衰减越陡峭。上线前务必用 EXPLAIN (ANALYZE) 看实际执行次数，别只信逻辑正确。
