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 场景下同样适用且更加直观——因为右侧是否为空，直接取决于每行动态计算的结果。