LEFT JOIN左表数据丢失是因为WHERE中对右表字段的非空条件过滤了NULL行，应将右表筛选条件移至ON子句；多表连接时需避免依赖前层可能为NULL的字段；COUNT(右表字段)才准确统计关联数量。
LEFT JOIN 为什么左表数据有时还是不显示？
LEFT JOIN 本身保证左表所有行参与结果集，但如果你发现左表某些行“消失”了，大概率是后续 WHERE 条件或 ON 中的右表字段过滤导致的。比如写成 WHERE r.status = 'active'（r 是右表别名），会把左表中对应右表为 NULL 的行整个剔除——这违背 LEFT JOIN 的本意。
正确做法是把对右表的筛选移到 ON 子句里：
SELECT l.id, l.name, r.order_id FROM users l LEFT JOIN orders r ON l.id = r.user_id AND r.status = 'active';
-
AND r.status = 'active'在ON中：保留所有users行，只匹配状态为 active 的订单；没匹配上的r.order_id为NULL -
WHERE r.status = 'active'在WHERE中：等价于内连接，users中没有 active 订单的行直接被丢弃
LEFT JOIN 后如何安全地判断右表是否匹配？
不能依赖右表字段值做非空判断，因为右表字段本身可能合法存 NULL（比如 orders.discount_code 允许为空）。真正可靠的依据是右表主键或连接字段是否为 NULL。
例如检查用户是否有订单：
SELECT l.name, CASE WHEN r.order_id IS NOT NULL THEN '有订单' ELSE '无订单' END AS has_order FROM users l LEFT JOIN orders r ON l.id = r.user_id;
- 用
r.order_id IS NOT NULL判断是否匹配成功，而不是r.total_amount IS NOT NULL（金额可能真为NULL） - 如果右表连接字段是复合主键，优先选最不可能为
NULL的字段，如r.id或r.order_id
多个 LEFT JOIN 时顺序和别名容易出什么错？
LEFT JOIN 是左关联，执行顺序从左到右，但很多人误以为可以随意调换表顺序。实际上，A LEFT JOIN B LEFT JOIN C 等价于 (A LEFT JOIN B) LEFT JOIN C，中间结果集成为下一次 JOIN 的“左表”。一旦某次 LEFT JOIN 后产生大量 NULL 行，后续 JOIN 可能放大空值，且难以调试。
- 确保每个
LEFT JOIN的ON条件都明确指向前一个结果集中的字段，比如第二层 JOIN 要用ON ab.col = c.col，而非ON a.col = c.col（a在子结果中可能已不可见或歧义） - 给每张表起清晰别名（
u,o,p），避免在多层 JOIN 中混淆字段来源 - 若需基于右表条件过滤整条链路，考虑用子查询或 CTE 预先过滤右表，而不是堆砌多个带条件的
ON
LEFT JOIN 性能差，是不是该换写法？
当左表大、右表也大，且 ON 条件缺乏索引时，LEFT JOIN 容易慢——数据库必须为左表每一行扫描右表找匹配。这不是语法问题，而是执行计划问题。
- 检查
EXPLAIN输出，确认右表连接字段（如orders.user_id）是否有索引；没有就加：CREATE INDEX idx_orders_user_id ON orders(user_id); - 避免在
ON中对字段做函数操作，如ON YEAR(r.created_at) = YEAR(l.registered_at)会导致索引失效 - 如果只是想查“左表哪些没匹配上”，用
NOT EXISTS通常比LEFT JOIN ... IS NULL更高效，尤其右表很大时
LEFT JOIN 的语义很干净，但它的“完整性”完全取决于你怎么写 ON 和 WHERE——漏掉一个 AND，就可能让左表悄悄变“不完整”。
