left join或inner join中on字段为null导致匹配失败，因null=anything结果为unknown而非true；应将右表条件移入on子句，用coalesce或is not distinct from显式处理null。
JOIN时ON条件字段为NULL导致意外丢数据
LEFT JOIN或INNER JOIN中，如果ON子句里参与匹配的字段本身含NULL，数据库不会将其视作“相等”，哪怕两边都是NULL——因为SQL标准规定NULL = NULL结果是UNKNOWN，不是TRUE。这会导致本该关联上的行被跳过。
- 常见现象：
LEFT JOIN后右表字段全为NULL，但查右表单独存在对应记录 - 典型场景：用户表
user用ref_id关联订单表order，但部分ref_id为NULL，这些用户在JOIN结果里“消失”（对INNER JOIN）或右表为空（对LEFT JOIN） - 解决思路：把
NULL显式转为可比较的占位值，例如COALESCE(ref_id, -1)，确保两边转换逻辑一致 - 注意：
COALESCE要和索引配合——如果原字段无索引，又在ON里加函数，可能使索引失效；优先考虑在写入时补默认值，而非查询时转换
用IS NULL / IS NOT NULL替代= NULL判断
很多人写WHERE ref_id = NULL想筛选空值，结果查不到任何数据——这是语法错误。SQL里不能用等号比对NULL，必须用专门的谓词。
-
WHERE ref_id IS NULL才能正确命中空值 -
WHERE ref_id IS NOT NULL等价于WHERE ref_id NULL（后者不推荐，语义不清） - 在
JOIN的ON条件中混用=和IS会破坏逻辑：比如ON u.ref_id = o.id OR u.ref_id IS NULL看似想兜底，实则让ON恒真，变成笛卡尔积风险 - 若真需“NULL也匹配”，应统一转义，如：
ON COALESCE(u.ref_id, -999) = COALESCE(o.id, -999)
LEFT JOIN + WHERE条件误把外连接变内连接
这是最隐蔽也最高频的陷阱：在LEFT JOIN后，对右表字段加WHERE非空判断，例如WHERE o.status = 'paid'，会导致左表没匹配上右表的行被整个过滤掉——效果等同于INNER JOIN。
- 原因：
WHERE是在JOIN结果生成后才执行的，此时未匹配行的o.status为NULL，NULL = 'paid'为UNKNOWN，被排除 - 正确做法：把右表的过滤条件移到
ON子句中，如LEFT JOIN order o ON u.id = o.user_id AND o.status = 'paid' - 例外情况：如果确实需要先LEFT JOIN再筛右表非空+状态，应显式写出
WHERE o.id IS NOT NULL AND o.status = 'paid'，但要清楚这已不是外连接语义
用COALESCE或CASE预处理关联字段再JOIN
当业务允许且数据量可控时，提前把可能为NULL的关联字段标准化，比在每次JOIN里动态处理更稳定、更易读、更利于索引利用。
- 建视图或CTE封装转换逻辑：
WITH clean_user AS ( SELECT id, COALESCE(ref_id, 0) AS join_key FROM user )
- 或在应用层写入时就约束：
INSERT INTO user (ref_id) VALUES (COALESCE(?, 0)) - 避免用
CASE WHEN ref_id IS NULL THEN 0 ELSE ref_id END代替COALESCE——功能等价但更冗长，且某些旧版MySQL对CASE在JOIN中的优化不如COALESCE - 注意负数占位值的风险：如果业务中真实
id可能为负，就别用-1，改用超范围值如-999999999，或字符串'__NULL__'（需字段类型支持）
SELECT COUNT(*) FROM table WHERE col IS NULL摸清NULL分布；JOIN结果出来后，用SELECT COUNT(*) FROM left_table和SELECT COUNT(DISTINCT join_key) FROM right_table交叉验证关联覆盖度——很多问题其实在执行前就能嗅到味道。
