CROSS JOIN 后加 WHERE 会先生成笛卡尔积再过滤，数据量大时性能极差甚至OOM；LATERAL 则让右侧子查询每行独立执行并引用左侧列，避免全量组合，是执行模型的根本改变。
为什么不能直接在 CROSS JOIN 后加 WHERE 限制关联逻辑？
因为 CROSS JOIN 本质是先生成笛卡尔积，再过滤——数据量大时会严重拖慢性能，甚至 OOM。比如两张各 10 万行的表，笛卡尔积就是 100 亿行，WHERE 再筛也晚了。真正需要的是“每行左表记录只关联满足条件的右表子集”，这得靠关联式展开，不是事后过滤。
LATERAL 在 PostgreSQL 中如何替代带条件的 CROSS JOIN
LATERAL 允许右侧子查询引用左侧列，且子查询对左侧每一行独立执行，天然避免全笛卡尔积。它不是语法糖，而是执行模型的根本改变。
- 必须显式写
LATERAL关键字（PostgreSQL 9.3+），不能省略 - 右侧必须是子查询（
(SELECT ...)形式），不能是表名或 CTE 直接引用 - 子查询中可使用左侧别名，如
t1.id，但不能出现在 FROM 子句顶层 - 若子查询返回 0 行，该左行仍保留（类似 LEFT JOIN），如需严格匹配，外层加
WHERE EXISTS或用JOIN LATERAL
示例：查每个用户最近 3 条订单
SELECT u.name, o.order_id, o.created_at FROM users u JOIN LATERAL ( SELECT order_id, created_at FROM orders WHERE user_id = u.id ORDER BY created_at DESC LIMIT 3 ) o ON true;
MySQL 和 SQL Server 怎么办？它们不支持 LATERAL
MySQL 8.0.14+ 支持 LATERAL，但仅限于派生表（即 FROM (SELECT ...) LATERAL 形式），不支持 JOIN LATERAL；SQL Server 完全不支持，得用等价结构替代。
- MySQL：用
FROM (SELECT ...) AS t LATERAL+JOIN，注意子查询必须有别名 - SQL Server：改用
OUTER APPLY（对应LEFT JOIN LATERAL）或CROSS APPLY（对应JOIN LATERAL） - SQLite、旧版 MySQL：只能用相关子查询 +
ROW_NUMBER() OVER (PARTITION BY ...)预计算序号，再外层过滤
SQL Server 等价写法：
SELECT u.name, o.order_id, o.created_at FROM users u CROSS APPLY ( SELECT TOP 3 order_id, created_at FROM orders WHERE user_id = u.id ORDER BY created_at DESC ) o;
容易被忽略的性能陷阱
LATERAL 不自动带来索引优化——如果子查询里用到的关联字段（如 user_id）没索引，每次子查询仍是全表扫描。
- 务必确保子查询 WHERE 条件中的左表引用字段，在右表上有合适索引（如
orders(user_id, created_at)复合索引） -
LIMIT在子查询中有效，但OFFSET会导致重复排序开销，慎用分页类逻辑 - 子查询若含聚合或窗口函数，可能触发物化，注意
EXPLAIN ANALYZE中的 “Materialize” 节点
最常被跳过的一步：没验证子查询是否真的按预期每行只跑一次。加个 pg_sleep(0.1) 测试延迟，就能暴露误写成全局子查询的问题。
