LEFT JOIN中子查询应优先用LATERAL（PostgreSQL/MySQL 8.0+）或OUTER APPLY（SQL Server）实现左表字段引用；若不可用，须将过滤条件下推至子查询内部，避免ON中NULL匹配导致左表行丢失。
LEFT JOIN 中的子查询必须写在 ON 子句里，不能放 FROM 后
很多人尝试把子查询直接写在 LEFT JOIN 关键字后面，比如 LEFT JOIN (SELECT ...) AS t2 ON ...，这在多数数据库（如 MySQL 5.7、PostgreSQL）是合法的，但一旦子查询里要引用左表字段，就会报错或结果异常。真正安全且通用的做法是把逻辑“下推”到 ON 条件中——也就是用子查询包裹右表匹配逻辑，并让它能访问左表别名。
典型错误现象：Unknown column 't1.id' in 'where clause'，说明子查询作用域没包含左表上下文。
- MySQL 8.0+ 和 PostgreSQL 支持
LATERAL（或JOIN LATERAL），可显式声明子查询依赖左表，推荐用于复杂计算 - SQL Server 用
OUTER APPLY替代，语义更清晰 - 如果只是过滤右表最新一条记录，优先考虑窗口函数（
ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...)）而非子查询，性能更好
用 LATERAL 实现带左表参数的动态右表查询（PostgreSQL / MySQL 8.0+）
LATERAL 是关键，它让右边的子查询可以引用左边的每一行，相当于“为左表每行执行一次子查询”。不加 LATERAL，子查询只执行一次，无法按需关联。
SELECT t1.name, t2.order_amount FROM users t1 LEFT JOIN LATERAL ( SELECT SUM(amount) AS order_amount FROM orders WHERE user_id = t1.id AND status = 'paid' ) t2 ON true;
注意：ON true 是必须的占位条件，因为 LATERAL 子查询本身不提供连接谓词；若想控制是否保留左表空行，仍靠 LEFT JOIN 语义保证。
- 子查询里不能出现聚合 + 非分组字段混用，否则报错（如
SUM() + created_at） - MySQL 中
LATERAL仅支持派生表（subquery in FROM），不支持直接跟在LEFT JOIN后；此时得改用(SELECT ... FROM DUAL WHERE ...)模拟 - PostgreSQL 对
LATERAL性能优化较好，但若子查询含全表扫描，整体变慢明显
SQL Server 的替代方案：OUTER APPLY 比 LEFT JOIN 子查询更可靠
SQL Server 没有 LATERAL，但 OUTER APPLY 功能完全等价，且语法更直白。它天然支持左表字段引用，失败时自动补 NULL，语义上就是“左连接 + 每行执行一次子查询”。
SELECT t1.name, t2.max_order FROM customers t1 OUTER APPLY ( SELECT MAX(total) AS max_order FROM orders WHERE customer_id = t1.id AND order_date >= DATEADD(month, -6, GETDATE()) ) t2;
和 LEFT JOIN (SELECT ...) ON ... 相比，OUTER APPLY 不会因子查询返回多行而引发笛卡尔积——它只取子查询结果集（即使多行也只关联第一行？不，实际是全部行都会参与连接，但常配合 TOP 1 使用）。
- 若子查询可能为空，
OUTER APPLY仍保留左表行，CROSS APPLY则退化为内连接 - 避免在
OUTER APPLY子查询里写ORDER BY不带TOP，SQL Server 可能报错 - 执行计划里容易看到子查询被“嵌套循环”展开，大数据量时注意索引覆盖
customer_id和order_date
常见陷阱：子查询放在 ON 里却忘了处理 NULL 匹配
当右表子查询没结果时，整个 ON 表达式变成 NULL，而 SQL 中 NULL = anything 永远为 UNKNOWN，导致左连接失效——左表行被意外过滤掉。这不是 bug，是三值逻辑的必然结果。
例如这个写法就有风险：
LEFT JOIN (SELECT * FROM logs WHERE type = 'error') t2 ON t2.user_id = t1.id AND t2.created_at > t1.signup_time
表面看是左连接，但如果子查询里 WHERE 条件太严，t2 根本没数据，那 t2.user_id = t1.id 就不会成立，左表行照样丢失。
- 正确做法：把过滤条件移到子查询内部，确保子查询至少返回结构化的空集（如用
SELECT ... FROM DUAL模拟），或改用LATERAL/OUTER APPLY - MySQL 5.7 不支持
LATERAL，此时可用LEFT JOIN (SELECT ...) t2 ON 1=1+ 在SELECT列里用CASE WHEN t2.id IS NOT NULL THEN ...控制逻辑 - 永远检查执行计划里的“Rows Removed by Join Filter”，数值大说明
ON条件正在悄悄丢弃左表行
复杂逻辑的左连接本质是控制“右表如何为每一行左表生成匹配集”，不是拼语法。子查询放哪只是手段，关键是让数据库引擎明白你想要的关联粒度——这点很容易被 EXPLAIN 或执行计划忽略。
