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，但你查的是最终结果，根本看不出中间断在哪一环。
