LEFT JOIN 产生 NULL 的根本原因是右表无匹配行，即左表某行在右表中找不到满足 ON 条件的记录，导致右表字段补 NULL；常见诱因包括右表数据缺失、字段类型不一致、空格/大小写干扰及 ON 条件错误；WHERE 中对右表字段过滤会隐式转为内连接，应将条件移至 ON 子句；应对 NULL 可采用 IFNULL/COALESCE 替换、聚合自动忽略、IS NULL 分支判断或修复源数据。
LEFT JOIN 产生 NULL，是因为它本就设计为保留左表全部记录——哪怕右表里找不到匹配项，也要把左表那条数据“撑出来”，而右表对应字段就填 NULL。
根本原因：右表无匹配行
LEFT JOIN 的逻辑是：先取左表每一行，再按 ON 条件 去右表找匹配的行。如果没找到，右表所有字段就补 NULL。
- 例如：
claims q LEFT JOIN msm_users u ON q.msm_user_uuid = u.uuid，某条 claim 的msm_user_uuid是'abc123'，但msm_users表里根本没有这个 uuid，那这行结果中u.role、u.avatar_base64全是 NULL。 - 哪怕
q.msm_user_uuid是 NULL，也会导致无法匹配（因为NULL = anything永远不成立），结果同样是 NULL。
常见诱因：连接条件出问题
不是 LEFT JOIN 本身有问题，而是 ON 条件没能真正“连上”：
- 右表主键或关联字段缺失：比如用户被删了，但订单表还留着旧的 uuid。
- 字段类型不一致：左表是字符串，右表是整型，隐式转换失败导致匹配不上。
- 空格或大小写干扰：如
'user1 '和'user1'看似一样，实际不等。 - ON 条件写错：比如误写成
q.id = r.user_id，但实际应是q.user_id = r.id。
WHERE 子句悄悄“废掉”了 LEFT JOIN
这是最容易踩的坑：在 WHERE 中对右表字段加非 NULL 条件，会把本该保留的 NULL 行过滤掉。
- 错误写法：
... LEFT JOIN u ON ... WHERE u.status = 1→ 实际变成内连接效果，NULL 行全被踢出。 - 正确做法：把右表的过滤条件移到 ON 后面，如
LEFT JOIN u ON ... AND u.status = 1，这样不满足 status=1 的行仍保留左表数据，只是 u 字段为 NULL。
怎么应对这些 NULL？
根据场景选处理方式，不一定要消灭 NULL：
- 展示层替换：用
IFNULL(u.name, '未知用户')或COALESCE(u.phone, '暂未填写', '—')。 - 统计时忽略：聚合函数如
COUNT(u.id)本来就会跳过 NULL，无需额外处理。 - 业务判断分支：比如
WHERE u.uuid IS NULL单独查出“未绑定用户”的记录做跟进。 - 修复数据源：查出
msm_user_uuid IS NULL或不存在的 uuid，补全或清理脏数据。
