LEFT JOIN 生成 NULL 是正常语义，非 bug；WHERE 中对右表字段过滤会意外转为 INNER JOIN 效果；ON 条件应纯净，匹配失败常因 NULL、类型不一致、不可见字符或函数导致。
LEFT JOIN 本身就会生成 NULL，这不是 bug 是语义
SQL 标准明确定义了 LEFT JOIN 的行为：左表每一行都必须出现在结果里，右表若无匹配行，所有右表字段统一填 NULL。这不是数据库“连不上”或“出错了”，而是你写了 LEFT JOIN 就必然发生的逻辑结果。
比如执行 SELECT u.name, o.total FROM users u LEFT JOIN orders o ON u.id = o.user_id，当某个用户没下过订单，o.total 就是 NULL——这恰恰说明 LEFT JOIN 正常工作了。
为什么你看到的全是 NULL？大概率是 WHERE 干的
最常见误操作：在 WHERE 子句里对右表字段加条件，比如 WHERE o.status = 'paid'。这个条件会把所有 o.status 为 NULL 的行直接过滤掉，最终只剩右表有匹配且满足条件的行——效果等同于 INNER JOIN。
- 错误写法：
LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 'paid' - 正确写法（想保留无订单用户）：
LEFT JOIN orders o ON u.id = o.user_id AND o.status = 'paid' - 正确写法（想查“已支付订单 + 无订单用户”）：保持
ON纯关联，再用WHERE o.status = 'paid' OR o.status IS NULL，但需确认业务是否真要这样混查
关联字段值为 NULL 或类型不一致，也会导致“匹配失败”
NULL = anything 永远返回 UNKNOWN，不是 TRUE，所以无法触发匹配。同样，隐式类型转换失败（如 INT 字段去匹配带空格的 VARCHAR 值）也会让 ON 条件始终不成立。
- 检查右表连接字段是否有
NULL：SELECT COUNT(*) FROM orders WHERE user_id IS NULL - 确认字段类型是否一致：
DESCRIBE users和DESCRIBE orders对比id与user_id - 排查不可见字符：
SELECT user_id, HEX(user_id) FROM orders WHERE user_id LIKE '%123%'，看 HEX 结果里有没有20（空格） - 避免在
ON里用函数（如UPPER()），否则索引失效，还可能因大小写规则导致匹配失败
怎么判断是不是真没数据，而不是逻辑写错了？
别一上来就改 SQL，先验证基础事实：
- 查左表本身有没有数据：
SELECT COUNT(*) FROM users - 单独查右表匹配数据是否存在：
SELECT * FROM orders WHERE user_id = 123（挑一个左表已知的id） - 用
SELECT *跑一遍原始LEFT JOIN，观察右表字段是否批量为NULL——这是匹配失败最直观的信号 - 如果嵌套了多层
LEFT JOIN（比如t1 LEFT JOIN (t2 LEFT JOIN t3 ON ...)），先拆开跑子查询，确认中间层有没有提前变空
真正难调试的，往往不是语法错，而是你默认“应该有关联”，但数据本身在源头就断了——比如用户被删了，订单还留着旧 user_id，或者同步脚本漏传了一部分关联值。
