LEFT JOIN后WHERE过滤右表字段会变INNER JOIN，因执行顺序是先JOIN后WHERE；应将右表条件移至ON子句或显式处理NULL。
WHERE 条件写在 LEFT JOIN 右表字段上，等于变 INNER JOIN
LEFT JOIN 后对右表字段加 WHERE 过滤，会导致左表没匹配的行被整体剔除——这不是 bug，是 SQL 执行顺序决定的：先完成 JOIN，再执行 WHERE。一旦右表字段为 NULL（比如 orders.status 不存在），WHERE orders.status = 'paid' 就不成立，整行被丢弃。
实操建议：
- 把右表的过滤条件挪到
ON子句里：LEFT JOIN orders ON users.id = orders.user_id AND orders.status = 'paid' - 如果必须用
WHERE，要允许 NULL：WHERE orders.status = 'paid' OR orders.status IS NULL（但语义通常已偏离原意） - 用
EXPLAIN看rows和filtered，对比改前改后是否丢失左表行数
ON 条件漏写关联字段，导致笛卡尔积式膨胀再截断
比如写成 LEFT JOIN orders ON orders.status = 'paid'，漏掉 users.id = orders.user_id，结果就是每个用户都和所有 paid 订单配一遍，数据量爆炸；后续加 LIMIT 或聚合时，看似有结果，实则随机丢数据。
常见错误现象：
- 查询变慢、内存暴涨、临时表写磁盘
-
COUNT(*)明显大于左表行数 - 用
SELECT *查几行就发现重复用户 + 多个订单混排
检查方法：
- 确认
ON中至少有一组明确的主外键等值条件 - 对多表 JOIN，逐个补全关联路径，不要依赖“反正后面 WHERE 会筛”
- 在测试库用小数据集加
SELECT COUNT(*)验证连接结果集大小
NULL 值参与比较导致条件失效
SQL 中 NULL = 'paid'、NULL != 'shipped' 全为 UNKNOWN，不进 WHERE 或 HAVING 的真值集合。尤其在 LEFT JOIN 后，右表字段为 NULL 是常态，直接拿它做等值判断必然漏数据。
典型场景：
-
WHERE order_amount > 100 AND status != 'cancelled'—— status 为 NULL 的行被排除 -
HAVING MAX(created_at) > '2024-01-01'—— 某分组无记录，MAX 返回 NULL，整个分组消失
安全写法：
- 显式处理 NULL：
status != 'cancelled' OR status IS NULL - 用
COALESCE(status, 'unknown')统一兜底值再比较 - 聚合前用
WHERE ... IS NOT NULL明确意图，避免隐式过滤
JOIN 顺序影响结果，但优化器不一定按你写的来
MySQL 5.7+ 的查询优化器可能重排 JOIN 顺序，尤其是当统计信息不准或缺少索引时。FROM a LEFT JOIN b ON ... INNER JOIN c ON ... 理论上先算 a LEFT JOIN b，再连 c；但如果优化器判定 c 更小、索引更好，它可能先连 c 再连 b，导致 LEFT JOIN 语义被破坏。
验证与应对：
- 加
STRAIGHT_JOIN强制顺序：SELECT STRAIGHT_JOIN ... FROM users LEFT JOIN orders ... INNER JOIN products ... - 用
EXPLAIN FORMAT=TREE（8.0+）或EXPLAIN的table列顺序确认实际执行流 - 给所有 JOIN 字段建联合索引，减少优化器“铤而走险”的动机
最麻烦的是嵌套子查询里套 JOIN，外层 WHERE 一推，内层逻辑可能被重写得面目全非——这种时候别省事，拆成临时表或 CTE 更可控。
