在SQL中执行LEFT JOIN后结果集为何会出现意想不到的NULL值？

LEFT JOIN失效是因为WHERE中对右表字段的非空条件过滤了NULL行，应将右表筛选条件移至ON子句；多层JOIN时尤其危险，外层WHERE含右表字段会导致整行丢失。

WHERE里写了右表字段，LEFT JOIN就失效了

最常被忽略的问题：把本该属于匹配逻辑的条件，错放在WHERE子句里。比如写LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid'，表面看是“查已支付订单+无订单用户”，实际结果只保留了有订单且状态为'paid'的行——所有o.status IS NULL的行（即没订单的用户）全被过滤掉了。

这是因为WHERE作用于JOIN完成后的中间结果集，而NULL = 'paid'永远不成立，直接剔除整行。正确做法是把右表筛选移到ON：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid'。这样左表行全保留，没匹配上的o.order_no仍是NULL，但整行还在。

多层嵌套时尤其危险：如果三层LEFT JOIN，只在最外层WHERE加t3.type = 'active'，会导致前两层的“左表全保留”完全失效——只要t3没匹配上，整行就消失。

连接字段本身就不匹配

ON条件不成立，LEFT JOIN只能填NULL，它不会报错，也不会提醒你字段对不上。常见原因有三个：

• NULL参与等值比较永远返回UNKNOWN，不是TRUE，所以u.id = o.user_id在任一端为NULL时必然失败
• 类型不一致：比如users.id是INT，orders.user_id是VARCHAR且存了'123 '（带空格），隐式转换后比较失败
• 不可见字符：用SELECT user_id, HEX(user_id) FROM orders WHERE user_id LIKE '%123%'查HEX结果，看到20就是空格，09是制表符

安全写法是显式处理：ON u.id = CAST(o.user_id AS SIGNED)或ON u.id = TRIM(o.user_id)。别在ON里用UPPER()这类函数，索引会失效，还可能因大小写规则导致匹配失败。

用ISNULL或COALESCE填空时踩坑

填空不是万能解药，函数选错或参数用错，可能掩盖问题甚至引入新bug：

• ISNULL是SQL Server特有，只接受两个参数，返回类型完全继承第一个参数——ISNULL(name, 'not_found_yet')在name是VARCHAR(10)时会截断成'not_found_'
• MySQL里ISNULL()是判断是否为NULL的函数，不能用来填空；得用IFNULL()或标准COALESCE()
• COALESCE支持多参数、类型推导更严谨：COALESCE(o.total, o.backup_total, 0)，但要注意NULL参与任何算术运算（如+、-）结果仍是NULL，填空必须在计算前做

嵌套JOIN中某一层先断掉，结果全是NULL

写SELECT * FROM t1 LEFT JOIN (t2 LEFT JOIN t3 ON ...) ON ...时，如果子查询或括号内JOIN本身因条件过严返回空集，外层LEFT JOIN就只能拿到一堆NULL——看起来像“整个结果为空”，其实是中间某层先断链了。

调试时别一上来就改SQL，先验证基础事实：

• 查左表本身有没有数据：SELECT COUNT(*) FROM t1
• 单独查右表匹配是否存在：SELECT * FROM t2 WHERE ref_id = 123（挑一个t1里已知的ID）
• 用SELECT *跑一遍原始LEFT JOIN，观察右表字段是否批量为NULL——这是匹配失败最直观的信号
• 拆开验证：SELECT * FROM t2 LEFT JOIN t3 ON ...先跑，确认是否有数据；再拿结果和t1关联

真正难调试的，从来不是“为什么有NULL”，而是“为什么没数据却看起来像有数据”。比如多层嵌套中某一层先因条件过严返回空集，外层只能拿到一堆NULL，但你查的是最终结果，根本看不出中间断在哪一环。