left join结果为空行的首要原因是on条件误写入where子句，导致null右表记录被过滤；其次需检查连接字段null值、类型不匹配、隐式转换、多层嵌套中间断链及统计信息过期等问题。
LEFT JOIN结果为空行，先检查ON条件是否写成WHERE
这是最常见也最容易忽略的问题：把本该写在ON里的过滤条件错放进了WHERE子句。LEFT JOIN 的语义是“保留左表全部记录”，但一旦在WHERE里加了右表字段的非空判断（比如WHERE t2.status = 'active'），就等效于把LEFT JOIN变成了INNER JOIN——因为NULL不满足任何等于判断，所有右表没匹配上的行都会被筛掉。
实操建议：
- 右表的筛选条件必须写进
ON，例如：ON t1.id = t2.ref_id AND t2.status = 'active' - 如果确实需要在JOIN后过滤右表数据，且想保留左表空匹配，改用
WHERE t2.status = 'active' OR t2.status IS NULL（但要小心逻辑是否符合业务） - 用
EXPLAIN或执行计划看实际是否走了索引，避免ON里写函数（如ON UPPER(t1.name) = UPPER(t2.name)）导致索引失效
右表连接字段存在NULL或隐式类型转换失败
LEFT JOIN依赖字段值精确匹配，但数据库对NULL和类型不一致的处理很严格：任何与NULL的等值比较都返回UNKNOWN，直接判定为不匹配；而字符串和数字混用（如t1.id = t2.ref_id，其中t2.ref_id是VARCHAR但存了'123 '带空格，或t1.id是INT）会触发隐式转换，可能全表扫描+匹配失败。
实操建议：
- 查右表连接字段是否有
NULL：SELECT COUNT(*) FROM t2 WHERE ref_id IS NULL - 确认字段类型是否一致，用
DESCRIBE t1和DESCRIBE t2比对；不一致时显式转换，如ON t1.id = CAST(t2.ref_id AS SIGNED) - 清理右表数据中的不可见字符：
SELECT ref_id, LENGTH(ref_id), HEX(ref_id) FROM t2 WHERE ref_id LIKE '%123%'，观察HEX结果是否有20（空格）或09（制表符）
LEFT JOIN多层嵌套时中间结果被意外过滤
写形如SELECT * FROM t1 LEFT JOIN (t2 LEFT JOIN t3 ON ...) ON ...时，如果子查询或括号内JOIN本身已因条件过严返回空集，外层LEFT JOIN就只能拿一堆NULL——看起来像“整个结果为空”，其实是中间某层先断掉了。
实操建议：
- 拆开验证：先单独跑
SELECT * FROM t2 LEFT JOIN t3 ON ...，看是否有数据；再用该结果作为临时表和t1关联 - 避免深层嵌套，优先用CTE（如
WITH t23 AS (SELECT ...) SELECT * FROM t1 LEFT JOIN t23 ...），可读性高，也方便逐层调试 - 注意MySQL 5.7及更早版本对FROM子句中子查询的物化限制，可能导致优化器误判，升级到8.0+或改用JOIN重写
连接字段有索引但统计信息过期，优化器选错执行顺序
即使字段有索引，如果表数据大量变更后未更新统计信息，优化器可能误判“右表更小”，把右表当驱动表，导致LEFT JOIN语义失效（实际执行变成右表驱动+左表被当被驱动表过滤）。
实操建议：
- 强制指定驱动表（MySQL）：
SELECT /*+ STRAIGHT_JOIN */ * FROM t1 LEFT JOIN t2 ON ... - 更新统计信息：
ANALYZE TABLE t1, t2（MySQL）、VACUUM ANALYZE t1, t2（PostgreSQL） - 查看执行计划中
rows预估是否严重偏离实际，若偏差大（比如预估10行，实际百万行），大概率是统计不准
真正麻烦的不是语法写错，而是那些看起来“应该能连上”的数据，因为一个空格、一次没刷新的统计信息、或者一句挪错了位置的WHERE，就彻底消失在结果集里。调试时别急着重写SQL，先盯住执行计划和原始字段值。
