标量子查询返回NULL时外层表达式静默变NULL，必须用COALESCE((SELECT...), default)兜底；WHERE中慎用=子查询，改用EXISTS；IN/NOT IN遇NULL逻辑失效，应换NOT EXISTS；多行关联优先LEFT JOIN而非标量子查询。
标量子查询返回NULL时，外层表达式直接变成NULL，不是报错，也不是跳过——它会静默污染计算、拼接和条件判断。必须主动兜底，不能指望它“自动消失”或“按0处理”。
标量子查询结果为NULL时，COALESCE必须包在外层
子查询本身没结果，整个表达式求值为NULL；COALESCE如果写在子查询内部（比如SELECT COALESCE(name, 'Unknown') FROM users），对空集无效。只有把它套在整个子查询外面，才能捕获“无结果”这个NULL。
- 错误：
SELECT COALESCE((SELECT name FROM users WHERE id = 999), 'Unknown')→ 这是对的；但写成(SELECT COALESCE(name, 'Unknown') FROM users WHERE id = 999)就无效，因为子查询根本没行可查，COALESCE压根不执行 - 正确：始终用
COALESCE((SELECT ...), default_value)结构 - 类型要一致：比如子查询返回
INT，默认值别写'N/A'，否则MySQL可能隐式转成0
WHERE中用子查询等值匹配，NULL会让整行消失
WHERE col = (SELECT ...)这类写法，一旦子查询返回NULL或空集，整个比较结果是UNKNOWN，该行被WHERE过滤掉——你查不到数据，也不会报错，容易误判为“没匹配上”。
- 别补救：
WHERE (SELECT ...) IS NOT NULL AND col = (SELECT ...)→ 触发两次子查询，性能翻倍 - 改用
EXISTS：语义清晰，不依赖值，也不怕NULL，例如WHERE EXISTS (SELECT 1 FROM users u WHERE u.id = orders.user_id AND u.status = 'active') - 真要保留标量逻辑，加
LIMIT 1并COALESCE兜底：(SELECT COALESCE(MAX(id), 0) FROM users WHERE ... LIMIT 1)
IN/NOT IN遇到子查询里的NULL，逻辑直接崩坏
col IN (SELECT x FROM t)只要子查询结果里有一个NULL，整个表达式变UNKNOWN，该行被过滤；NOT IN更危险——哪怕只有一个NULL，结果集必然为空。
- 别手动剔NULL：
NOT IN (SELECT x FROM t WHERE x IS NOT NULL)→ 治标不治本，且漏掉业务上可能合法的NULL状态 - 一律换
NOT EXISTS：WHERE NOT EXISTS (SELECT 1 FROM t WHERE t.x = outer.col) -
IN场景优先考虑EXISTS重写，尤其当子查询来自可能含NULL的业务表（如orders.user_id）
LEFT JOIN比标量子查询更稳，也更容易兜底
用SELECT (SELECT name FROM users WHERE id = o.user_id)这种写法，每行都触发一次子查询，性能差；而LEFT JOIN users u ON o.user_id = u.id只扫一次users表，还能自然把缺失关联转成NULL字段，再用COALESCE(u.name, 'Unknown')统一处理。
- 标量子查询适合极简场景（比如查单个配置项），但别用于主表多行关联
-
LEFT JOIN能暴露数据关联缺失的真实问题，而不是靠IFNULL掩盖 - 注意
ON条件里别混用NULL判断（如ON u.id = o.user_id AND u.deleted_at IS NULL），否则可能意外丢行
最易被忽略的是：空结果集 ≠ 字段为NULL，这两者触发的处理路径完全不同。前者需要COALESCE(子查询, 默认值)，后者才轮到COALESCE(字段, 默认值)。混淆这两者，是绝大多数NULL相关偏差的起点。
