lateral本身不带left或inner修饰，真正决定连接语义的是其前的join类型：left join lateral保留左侧行（右为空则NULL），inner join lateral仅保留右侧有结果的左侧行。
sql 中 LATERAL 本身不带 LEFT 或 INNER 修饰；真正决定连接语义的是 LATERAL 前面的 JOIN 类型（如 LEFT JOIN LATERAL 或 INNER JOIN LATERAL）。关键差异在于：当右侧子查询（LATERAL 子句）对某一行返回空结果集时，LEFT JOIN LATERAL 保留左侧行（右侧列补 NULL），而 INNER JOIN LATERAL 丢弃该行。
LEFT JOIN LATERAL：保留左侧行，右侧为空则填 NULL
即使 LATERAL 子查询对当前左侧行返回零行，整行仍保留在结果中，子查询中的列全部为 NULL。这与普通 LEFT JOIN 行为一致，只是右侧可引用左侧列。
例如：
SELECT u.id, u.name, o.order_id, o.amount FROM users u LEFT JOIN LATERAL ( SELECT order_id, amount FROM orders WHERE orders.user_id = u.id AND orders.status = 'paid' LIMIT 1 ) o ON true;效果：每个用户都出现一次；有“已支付订单”的显示对应订单信息，没有的则 order_id 和 amount 为 NULL。
INNER JOIN LATERAL：仅保留右侧有结果的左侧行
只有当 LATERAL 子查询至少返回一行时，左侧行才进入最终结果。它等价于“带相关子查询的内连接”，天然过滤掉子查询无输出的左侧行。
相同例子改写：
SELECT u.id, u.name, o.order_id, o.amount FROM users u INNER JOIN LATERAL ( SELECT order_id, amount FROM orders WHERE orders.user_id = u.id AND orders.status = 'paid' LIMIT 1 ) o ON true;效果：只返回至少有一个已支付订单的用户；无符合条件订单的用户完全不出现在结果中。
常见误区：LATERAL 不是独立连接类型
LATERAL 是一个修饰符，用于允许右侧子查询引用左侧表的列，它必须依附于某种 JOIN（INNER、LEFT、RIGHT、FULL）。单独写 LATERAL JOIN 语法错误——必须明确写出 INNER JOIN LATERAL 或 LEFT JOIN LATERAL 等完整形式。
- postgresql、Snowflake、BigQuery 支持完整语法；mysql 8.0+ 仅支持
JOIN LATERAL（隐含INNER），不支持LEFT JOIN LATERAL。 -
ON true在 LATERAL 连接中常被省略（部分引擎允许），但显式写出更清晰，强调连接条件恒真，逻辑完全由子查询驱动。 - 性能上，LATERAL 子查询对左侧每行执行一次，需注意子查询是否可高效利用索引，避免全表扫描放大 N 倍。
如何选择：看业务是否需要“无匹配也保留”
用 LEFT JOIN LATERAL 当你需要完整主表视图（如统计每个用户的最新订单，包括零单用户）；用 INNER JOIN LATERAL 当你只关心存在关联数据的记录（如列出所有有活跃订阅的用户及其最新订阅项）。
本质上，这不是 LATERAL 的特性差异，而是 LEFT vs INNER 连接在“空右侧行”处理上的通用规则，在 LATERAL 场景下同样适用且更加直观——因为右侧是否为空，直接取决于每行动态计算的结果。