LEFT JOIN后WHERE过滤右表字段会使连接退化为INNER JOIN；正确做法是将右表过滤条件移至ON子句，确保左表全量保留，避免数据丢失。
LEFT JOIN后WHERE里写右表条件，直接让连接退化成INNER JOIN
这是最常被忽略、也最容易引发线上问题的操作。表面上看只是把过滤条件挪了个地方，实际执行计划和结果集会彻底改变。
典型错误写法：SELECT u.name, o.order_no FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'——这条语句查出来的全是已支付订单的用户，但users 表里没下单或下单未支付的用户全被过滤掉了，LEFT JOIN 形同虚设。
原因很简单：WHERE 是在 JOIN 完成后对最终结果做筛选，此时 o.status 为 NULL 的行（即没匹配到订单的用户）不满足 = 'paid'，直接被丢弃。
- 正确做法是把右表过滤逻辑放进
ON子句：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 这样保留了所有
users行，只关联那些状态为'paid'的订单；没匹配上的，o.order_no仍是 NULL，但整行还在 - 如果用的是 MySQL，注意
ON中的条件不能引用左表字段以外的列（比如不能写AND o.created_at > u.registered_at），否则可能报错或行为异常
多层LEFT JOIN时，每一层的右表条件都必须放在对应ON里
嵌套三层 LEFT JOIN 后，若只在最外层 WHERE 里加一个 t3.type = 'active'，会导致前两层的 LEFT JOIN 全部失效——只要 t3 没匹配上，整行就被干掉。
实操要点：
- 每层 JOIN 的右表过滤条件，必须紧贴在该层的
ON后面，例如：LEFT JOIN t2 ON t1.id = t2.t1_id AND t2.deleted = 0 - 如果某层需要“有且仅有某种状态的关联”，就用
AND补在 ON 里；如果想后续再统一筛，就用CASE WHEN或COALESCE做字段级兜底，别动 WHERE - PostgreSQL 和 SQL Server 对
ON中复杂表达式支持较好；MySQL 5.7 及更早版本在ON里用子查询可能触发警告，建议拆成 JOIN 前的 CTE 预处理
用 EXISTS/NOT EXISTS 替代“LEFT JOIN + IS NULL”来判断缺失关联
当业务逻辑本质是“查没有对应记录的主表数据”，比如“查从未下单的用户”，写成 LEFT JOIN orders o ON u.id = o.user_id WHERE o.id IS NULL 看似合理，但容易因索引缺失或统计信息不准导致性能骤降，尤其在大表上。
更稳的写法是：
- 用
NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)—— 明确语义，优化器更容易走索引 - 避免在
WHERE中对右表字段做函数操作，比如WHERE COALESCE(o.status, 'draft') = 'shipped'，这会让索引失效，且逻辑上已违背 LEFT JOIN 初衷 - 如果真要结合状态查“未支付且无订单”，优先组合
NOT EXISTS+AND，而不是堆 LEFT JOIN
COALESCE 放在 SELECT 里安全，但别指望它救活 WHERE 里的逻辑错误
COALESCE(o.order_no, 'N/A') 这类写法只影响输出值，不影响行存留。很多人以为加了这个就能“看到所有用户”，结果发现报表里还是缺人——其实是 WHERE 已经提前把行砍掉了。
关键提醒：
-
COALESCE是展示层补位，不是连接逻辑修复工具 - 若需按补后的值分组或筛选（如
GROUP BY COALESCE(o.status, 'no_order')），务必确认原始 NULL 行是否真的还在结果集中——先检查执行计划里的 Rows Returned，别只看 SELECT 那一行 - SQLite 对
COALESCE内嵌子查询支持弱，遇到COALESCE((SELECT ...), 'default')可能全表扫描，不如拆成两个查询或改用CASE WHEN
真正卡住多数人的，从来不是函数怎么写，而是没意识到 WHERE 和 ON 的执行阶段差了一整个 JOIN 结果集。一旦习惯把右表条件往 ON 里塞，很多“查不到数据”的问题就自动消失了。
