left join出现“意想不到的空值”主因是where中误写右表条件导致null行被过滤，应将右表筛选移至on子句；其次为连接字段存在null、类型不匹配或隐式转换失败。
LEFT JOIN 出现“意想不到的空值”，基本不是数据库出错，而是你写的条件或数据本身触发了它的标准语义——左表行强制保留，右表无匹配就填 NULL。真正的问题往往藏在写法、数据质量或执行顺序里。
WHERE 里写了右表字段，LEFT JOIN 就悄悄变 INNER JOIN
这是最隐蔽也最常踩的坑：把本该属于匹配逻辑的条件，错扔进 WHERE 子句。
-
WHERE o.status = 'paid'会过滤掉所有o.status IS NULL的行，也就是把没订单的用户全踢掉 - 正确做法是把筛选移到
ON：LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 如果业务真要“已支付订单 + 无订单用户”，得写成
WHERE o.status = 'paid' OR o.status IS NULL，但多数场景并不需要这种混合逻辑
连接字段值不“相等”，根本就匹配不上
ON 条件不成立，LEFT JOIN 只能给你 NULL —— 它不会报错，也不会提醒你“这俩字段其实对不上”。
-
NULL = anything永远返回UNKNOWN，不是TRUE，所以任何含NULL的连接键都匹配失败 - 类型不一致：比如
users.id是INT，orders.user_id是VARCHAR且存了'123 '（带空格），隐式转换后比较失败 - 验证方式：
SELECT user_id, HEX(user_id), LENGTH(user_id) FROM orders WHERE user_id LIKE '%123%'，看有没有20（空格）或09（制表符） - 安全写法：
ON u.id = CAST(o.user_id AS SIGNED)或ON u.id = TRIM(o.user_id)
用 ISNULL / COALESCE 填空时，类型和兼容性容易翻车
填空不是万能解药，函数选错或用错参数，可能掩盖问题，甚至引入新 bug。
-
ISNULL是 SQL Server 特有，只接受两个参数，且返回类型完全继承第一个参数——ISNULL(name, 'not_found_yet')在name VARCHAR(10)下会截断为'not_found_' -
COALESCE是标准函数，支持多参数、类型推导更严谨：COALESCE(o.total, o.backup_total, 0) - MySQL 用户不能用
ISNULL()（那是判断是否为NULL的函数），得用IFNULL()或COALESCE() - 注意：
NULL参与任何算术运算（如+ - * /）结果仍是NULL，填空必须在计算前做
真正难调试的，从来不是“为什么有 NULL”，而是“为什么没数据却看起来像有数据”——比如多层嵌套 LEFT JOIN 中某一层先因条件过严返回空集，外层只能拿到一堆 NULL，但你查的是最终结果，根本看不出中间断在哪一环。
