子查询返回null时外层where条件失效：标量子查询无匹配或含null均转为unknown，被where过滤；not in遇null恒为unknown；应优先用exists/not exists替代=、in/not in，显式处理缺失。
子查询返回NULL时，外层WHERE条件直接失效
当子查询用在 WHERE col = (SELECT ...) 或 WHERE col IN (SELECT ...) 这类等值/集合判断中，只要子查询结果为 NULL（包括空集或字段本身是 NULL），整个表达式就变成 UNKNOWN。而 WHERE 只保留 TRUE 行，UNKNOWN 和 FALSE 都被过滤——你查不到数据，也不会报错，只会“静默消失”。
常见触发场景：
- 标量子查询没匹配到任何行（如
(SELECT name FROM users WHERE id = 999)）→ 自动转为NULL - 子查询字段含
NULL（如SELECT user_id FROM orders WHERE status = 'shipped'中有user_id IS NULL记录） -
NOT IN子查询里出现NULL→ 整个条件恒为UNKNOWN，结果集为空
别用 IFNULL/COALESCE 包裹标量子查询来兜底
写成 WHERE col = COALESCE((SELECT id FROM t WHERE x = ?), 0) 看似安全，实则埋雷：
- 性能差：每行都执行一次子查询，N 行就是 N 次全表扫描（尤其没索引时）
- 语义错：把“找不到”硬改成“等于 0”，可能误命中真实值为 0 的记录
- 掩盖问题：本该报警或补数据的关联缺失，被悄悄吞掉
真正健壮的做法是改用 EXISTS 或 LEFT JOIN，让逻辑显式、可推演。
用 EXISTS 替代 = 或 IN 子查询更安全
EXISTS 天然不关心 NULL：它只判断子查询是否返回至少一行，内部字段是否为 NULL 完全不影响结果。
对比写法：
- 危险写法：
WHERE user_id = (SELECT id FROM users WHERE email = 'a@b.com')→ email 不存在时整行消失 - 安全写法：
WHERE EXISTS (SELECT 1 FROM users u WHERE u.email = 'a@b.com' AND u.id = orders.user_id)
注意两点：
- 必须把外层字段（如
orders.user_id）拉进子查询的WHERE条件，构成相关子查询 - 子查询里用
SELECT 1即可，避免无谓字段传输
IN/NOT IN 场景必须显式排除 NULL
如果非用 IN 不可，子查询必须加 WHERE col IS NOT NULL；NOT IN 更建议直接弃用，改用 NOT EXISTS。
例如：
- 错误：
WHERE id NOT IN (SELECT user_id FROM orders)→ orders.user_id 含NULL就崩 - 勉强修复：
WHERE id NOT IN (SELECT user_id FROM orders WHERE user_id IS NOT NULL) - 推荐替代：
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = t_user.id)
NOT EXISTS 不仅避开 NULL 坑，还能利用索引（比如 orders(user_id)），而 NOT IN 在多数引擎里无法走索引。
最常被忽略的一点：NULL 不是“空”，也不是“零”，它是“未知”。所有试图用普通比较或算术运算去“覆盖”它的做法，都在绕开问题本质。真正的防御，是让查询逻辑本身对缺失保持鲁棒——用 EXISTS 代替等值，用 LEFT JOIN + COALESCE 代替标量，把 IS NULL 当作第一等公民写进条件，而不是最后补救的兜底手段。
