子查询返回空值时会静默转为NULL，污染外层计算与判断逻辑；应优先用LEFT JOIN+COALESCE或EXISTS替代标量子查询，避免NOT IN、WHERE等因NULL导致逻辑失效。
子查询返回空值（NULL）时，不会报错，但会悄悄污染外层计算和判断逻辑——尤其是AVG()、SUM()、WHERE条件或字符串拼接中，它直接让整条表达式变成NULL，而不是“跳过”或“按0处理”。这正是统计偏差最隐蔽的源头。
标量子查询没结果？别指望它安静变NULL
像 SELECT id, (SELECT name FROM users WHERE id = orders.user_id) AS user_name FROM orders 这种写法，只要某条 orders.user_id 在 users 表里不存在，user_name 就是NULL。后续用 WHERE user_name = 'Alice' 或 CONCAT('Hi, ', user_name) 都会意外中断。
- 它不是错误，是静默行为：MySQL允许标量子查询返回空集，并自动转为NULL；PostgreSQL或SQL Server则可能直接报错“subquery returns no rows”
- 别用
IFNULL((SELECT ...), 'Unknown')临时兜底——性能差（N行触发N次子查询），且掩盖了数据关联缺失的真实问题 - 真正健壮的做法是改用
LEFT JOIN users ON orders.user_id = users.id，再配合COALESCE(users.name, 'Unknown')
WHERE中用子查询等值匹配？NULL会让条件永远不成立
WHERE customer_id = (SELECT id FROM customers WHERE name = 'Alice') 看似简洁，但一旦 'Alice' 不存在，整个等号表达式结果是UNKNOWN（不是FALSE），该行被WHERE过滤掉——你查不到任何记录，连空提示都没有。
- 错误补救：
WHERE (SELECT id FROM customers WHERE name = 'Alice') IS NOT NULL AND customer_id = (SELECT id FROM customers WHERE name = 'Alice')→ 触发两次子查询，性能翻倍 - 正确替代：用
EXISTS，语义清晰又高效：WHERE EXISTS (SELECT 1 FROM customers c WHERE c.name = 'Alice' AND c.id = orders.customer_id) - 如果必须用标量，加
LIMIT 1+COALESCE强制兜底：(SELECT COALESCE(MAX(id), 0) FROM customers WHERE name = 'Alice' LIMIT 1)
AVG/SUM被NULL拉偏？先搞清分母到底是多少
AVG(price) 默认跳过NULL，但把0当有效值；而 AVG(IFNULL(price, 0)) 把NULL当0算——两者分母完全不同，结果可能差一倍。光看平均值数字，根本看不出问题。
- 查清基数：执行
SELECT AVG(price), COUNT(price), COUNT(*), COUNT(NULLIF(price, 0)) FROM orders - 想排除0值（比如0是测试单）：用
AVG(NULLIF(price, 0))，它把0转成NULL，让AVG自然跳过 - 想把NULL当0参与计算（比如“未报价=0”）：用
AVG(COALESCE(price, 0))，但必须确认业务上这个默认值合理 - 别写
WHERE price IS NOT NULL来“清洗”——它会丢弃整行，影响其他字段的聚合上下文（比如同时要统计订单数、客户数）
NOT IN遇到NULL？结果直接变空集
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders WHERE status = 'shipped') 看起来没问题，但如果子查询里有任意一条 user_id 是NULL（比如日志字段允许为空），整个 NOT IN 条件恒为UNKNOWN，结果集为空——哪怕99%的用户真没下单。
- 现象：明明有数据，执行计划显示
Filter: (users.id not in <subquery>)</subquery>却没结果 - 根治方案：换
NOT EXISTS——它不受NULL影响，且数据库通常能用索引提前终止：WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = users.id AND o.status = 'shipped') - 若坚持用
IN类写法，子查询里必须显式过滤：WHERE user_id IN (SELECT user_id FROM orders WHERE status = 'shipped' AND user_id IS NOT NULL)
空值处理最难的不是语法，而是判断“这个NULL到底代表什么”：是缺失、未知、未发生，还是数据异常？盲目用 COALESCE 或 IFNULL 填0或字符串，常比留着NULL更危险——它让问题沉得更深，直到报表上线才爆发。
