LEFT JOIN后左表数据“消失”主因是WHERE中引用右表字段，导致NULL行被过滤；应将右表筛选条件移至ON子句，并注意COUNT(*)与COUNT(右表字段)语义差异。
LEFT JOIN 为什么有时左表数据还是“消失”了
LEFT JOIN 本意是保留左表全部行，但实际执行后左表某些行没出现，大概率是因为 WHERE 条件写在了连接之后、且条件中引用了右表字段。比如 WHERE t2.status = 'active' 会把右表为 NULL 的那些左表行直接过滤掉——这和 LEFT JOIN 的语义冲突。
正确做法是把对右表的筛选逻辑移到 ON 子句里：
SELECT t1.id, t1.name, t2.order_id FROM users t1 LEFT JOIN orders t2 ON t1.id = t2.user_id AND t2.status = 'active';
-
ON中的t2.status = 'active'只影响连接匹配，不丢左表行 -
WHERE中写t2.status = 'active'等价于把LEFT JOIN当成INNER JOIN用 - 如果需要区分“有 active 订单”和“无订单”，可加
CASE WHEN t2.order_id IS NOT NULL THEN 'yes' ELSE 'no' END
LEFT JOIN 后 COUNT(*) 和 COUNT(右表字段) 的区别
统计时容易误用 COUNT(*)，它会把左表每行都算一次（包括右表为 NULL 的行），而 COUNT(t2.id) 只统计右表非 NULL 的匹配行——这是判断“是否有关联数据”的关键。
- 查每个用户有多少个订单：
COUNT(t2.order_id)（结果含 0） - 查结果集总行数：
COUNT(*)（等于左表行数，无论右表有没有匹配） - 想排除无订单用户？别改
LEFT JOIN，改用HAVING COUNT(t2.order_id) > 0配合GROUP BY
多表 LEFT JOIN 顺序和性能影响
MySQL 和 PostgreSQL 对 LEFT JOIN 顺序敏感：左表固定，后续每个 LEFT JOIN 都基于前一步结果扩展列。如果中间某步右表过大或缺乏索引，性能会断崖式下降。
- 优先让小表或高过滤性表做左表（如
users比logs小得多） - 确保
ON条件字段都有索引，尤其是右表被连接字段（如orders.user_id） - 避免
LEFT JOIN A ON ... LEFT JOIN B ON ... LEFT JOIN C ON ...中 C 依赖 A 字段却没通过 B 中转——可能产生笛卡尔积
NULL 值处理：COALESCE 和 IS NULL 判断要配合字段来源
左表字段不会因 LEFT JOIN 变成 NULL，但右表字段会。所以 WHERE t1.name IS NULL 永远不成立；而 WHERE t2.order_id IS NULL 才能找出“没订单的用户”。
- 用
COALESCE(t2.amount, 0)把空金额转成 0，但注意：它不能替代IS NULL判断逻辑 - 聚合时若需按右表分组，必须先用
WHERE t2.id IS NOT NULL过滤，否则GROUP BY t2.category会把所有NULL归为一组 - 视图或子查询中嵌套
LEFT JOIN，外部再加WHERE仍可能意外丢左表行——检查执行计划里的filtered值
真正难的不是写对 LEFT JOIN，而是意识到它的结果集结构已经变了：每行左表数据可能对应零行、一行或多行右表数据，而 SQL 的平面行结构会让这种“一对多”关系变得隐晦。一旦加了聚合、排序或嵌套，就很容易在不知不觉中破坏左表完整性。
