left join中on条件含null时匹配失败，因sql三值逻辑下null参与比较结果为unknown而非true；应将右表过滤条件移入on子句，用coalesce或is not distinct from显式处理null。
LEFT JOIN 后 ON 条件里字段为 NULL，为什么没匹配上？
因为 ON 子句中的比较（比如 a.id = b.user_id）在 SQL 标准下，一旦任一操作数为 NULL，整个表达式结果就是 UNKNOWN，不是 TRUE，所以不满足连接条件。这不是 bug，是三值逻辑的必然结果。
常见错误现象：LEFT JOIN 本该保留左表全部行，但右表某些本应能关联的记录“消失”了——其实是 ON 里用了可能为 NULL 的字段直接比较，导致匹配失败。
- 别在
ON中写b.user_id = a.id，如果b.user_id可能为NULL - 想让
NULL也能参与匹配？得显式处理：用IS NOT DISTINCT FROM（PostgreSQL/SQL:2003 支持），或退而求其次用COALESCE(b.user_id, -1) = COALESCE(a.id, -1)（注意选一个业务中绝对不出现的兜底值） - 更安全的做法是：把对右表字段的
NULL过滤挪到WHERE或后续逻辑里，而不是塞进ON
LEFT JOIN + WHERE 右表字段 IS NULL，为什么变成交叉过滤？
很多人想“查左表有、右表无”的记录，就写 LEFT JOIN ... WHERE b.id IS NULL，这本身没错；但如果 WHERE 里还加了 b.status = 'active' 这类条件，整条语句就等价于 INNER JOIN 了——因为 WHERE 是在连接后过滤，b.status = 'active' 会把所有 b 行为 NULL 的结果全干掉。
使用场景：排查“订单有但用户信息缺失”或“用户存在但没对应配置”。这时候你要的是“左表存在，且右表要么没匹配上，要么匹配上了但不满足状态”，那就不能把状态判断放 WHERE。
- 把右表的业务条件（如
status、deleted_at IS NULL）全部移到ON子句里：LEFT JOIN users u ON o.user_id = u.id AND u.status = 'active' - 这样即使
u.status不满足，也不会让整行被过滤，只是u.*字段为NULL - 记住口诀：
ON控制“怎么连”，WHERE控制“连完留哪些行”
用 COALESCE 或 CASE 处理连接后字段为空的显示问题
连接完成之后，右表字段天然可能是 NULL，但业务前端或报表常要求默认值（比如“未知用户”、“暂无分类”）。这时候别靠应用层 if-else 填充，SQL 层就能干净解决。
性能影响很小，但要注意：如果在 SELECT 里对连接字段做函数包装（如 COALESCE(u.name, '匿名')），不会影响连接逻辑，也不会拖慢索引使用——只要函数不作用在 ON 或 WHERE 的连接键上。
- 简单替换用
COALESCE(u.name, '未知')，支持多备选：COALESCE(u.nickname, u.name, '访客') - 复杂逻辑用
CASE WHEN u.id IS NULL THEN '未登录' ELSE u.name END - 避免写
IFNULL(u.name, '')（MySQL 特有），跨数据库时换成COALESCE更稳妥
LEFT JOIN 多次嵌套时 NULL 传播容易漏判
比如 orders → LEFT JOIN users → LEFT JOIN profiles，当 users.id 是 NULL，那 profiles 这一层根本不会去查——因为连接条件 u.id = p.user_id 左边已经是 NULL，整个表达式不成立。结果是 p.* 全为 NULL，但你可能误以为“用户有，只是没资料”，其实“用户都不存在”。
这种链式空值容易掩盖真实数据断点。调试时别只看最终结果是否为 NULL，要逐层确认中间表字段是否也为 NULL。
- 检查中间状态：在
SELECT里显式写出u.id、p.id等关键连接字段，一眼看出在哪断的 - 必要时拆成子查询或 CTE，强制分步控制空值流向，比如先
WITH valid_users AS (SELECT * FROM users WHERE id IS NOT NULL) - 连接字段类型不一致（如
INTvsVARCHAR）也会隐式转成NULL再比较，务必核对列定义
空值不是异常，是数据模型的一部分；但把它当成“没值”来处理，和当成“未知”来建模，得到的 SQL 逻辑完全不同。
