LEFT JOIN失效是因为WHERE中对右表字段的非空条件过滤了NULL行，应将右表筛选条件移至ON子句；多表连接时需避免依赖前层可能为NULL的字段；COUNT(右表字段)才准确统计关联数量。
WHERE里写了右表字段，LEFT JOIN就失效了
LEFT JOIN 本该保留左表所有行，但结果里左表数据变少了——八成是因为 WHERE 子句里对右表字段加了非空条件，比如 WHERE t2.status = 'active' 或 WHERE t2.created_at > '2024-01-01'。这类条件会在连接完成后执行，把右表为 NULL 的整行直接过滤掉，LEFT JOIN 实际退化成了 INNER JOIN。
根本原因是 SQL 执行顺序：ON 先执行（决定怎么连），WHERE 后执行（决定留哪些行）。右表没匹配上的行，其字段全是 NULL，而 NULL = 'active' 或 NULL > '2024-01-01' 全部判定为 FALSE，不满足 WHERE 条件，就被踢了。
右表筛选条件必须塞进 ON，不能放 WHERE
想保留左表全部记录，同时只关联右表中符合条件的行，就得把右表的筛选逻辑挪到 ON 子句里，用 AND 连接：
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';
这样，t2.status = 'active' 只影响“是否建立连接”，不影响“是否保留左表行”。没匹配上或匹配上但状态不是 active 的，t2.order_id 都是 NULL，但 t1 行还在。
- 错误写法：
LEFT JOIN ... ON t1.id = t2.user_id WHERE t2.status = 'active'→ 左表丢行 - 正确写法：
LEFT JOIN ... ON t1.id = t2.user_id AND t2.status = 'active' - 如果真要查“左表有、右表无”的情况，得用
WHERE t2.user_id IS NULL，且前面不能有任何干扰WHERE条件
多层 LEFT JOIN 时，别让上层 NULL 污染下层连接
连续 LEFT JOIN 多张表时，第二层连接依赖第一层结果。如果第一层右表字段是 NULL（比如 t2.product_id 是 NULL），那么 ON t2.product_id = t3.id 必然失败，导致 t3 字段全 NULL ——这不是 bug，是逻辑必然。
若业务要求“即使没订单，也要带出用户偏好的商品”，就不能写：
LEFT JOIN products t3 ON t2.product_id = t3.id
而应改用独立关联：
LEFT JOIN products t3 ON t1.preferred_product_id = t3.id
关键点：
- 每层
JOIN的连接字段尽量来自左表（如t1.preferred_product_id），避免依赖前一层可能为NULL的字段 - 所有表别名在
FROM和ON中必须一致，不能前边用t1，后边写users.id - 调试时先
SELECT *看右表字段是否批量为NULL，快速定位哪一层断开了
LEFT JOIN 后 COUNT(*) 和 COUNT(右表字段) 差很多
这是 LEFT JOIN 的正常表现，但常被误认为“数据丢了”。COUNT(*) 统计所有返回行数（含右表为 NULL 的行），COUNT(t2.id) 只统计 t2.id 非 NULL 的行数。
例如统计“每个用户下了几单”，正确写法是：
SELECT t1.name, COUNT(t2.order_id) AS order_count FROM users t1 LEFT JOIN orders t2 ON t1.id = t2.user_id AND t2.status = 'paid' GROUP BY t1.id;
这里必须用 COUNT(t2.order_id)，而不是 COUNT(*)，否则所有用户都会显示至少 1 单（因为左表每行都存在）。
容易忽略的细节：
- 如果右表主键允许
NULL（极少见），COUNT(t2.pk)不可靠，改用SUM(CASE WHEN t2.pk IS NOT NULL THEN 1 ELSE 0 END) -
COUNT(t2.some_column)会自动忽略NULL，不用额外WHERE过滤 - 聚合前务必确认
ON条件已正确隔离右表逻辑，否则COUNT结果毫无业务意义
