子查询返回NULL时WHERE条件失效，因NULL参与比较结果为UNKNOWN，被WHERE过滤；应改用EXISTS/NOT EXISTS替代=或IN/NOT IN，并用COALESCE显式兜底。
子查询返回NULL时WHERE条件失效
SQL里用子查询做比较（比如 WHERE col = (SELECT ...)）时，如果子查询结果是 NULL，整个表达式会变成 UNKNOWN，而不是 TRUE 或 FALSE —— 这意味着那行数据直接被过滤掉，不是你“没查到”，而是它根本没进结果集。
常见现象：你确认子查询能查出值，但主查询却空着；或者只在子查询有明确非NULL结果时才返回数据。
- 用
IS NULL或IS NOT NULL显式判断子查询结果，例如：WHERE (SELECT price FROM products WHERE id = 100) IS NOT NULL - 改用
IN替代=：因为col IN (SELECT ...)在子查询返回NULL时仍可匹配非NULL项（但注意：IN遇到NULL本身不会导致整行消失，逻辑更安全） - 避免在
=左右直接放可能为NULL的子查询，优先用EXISTS或JOIN重写逻辑
COALESCE和CASE处理子查询NULL结果
当你要把子查询结果当作一个值参与计算或展示，又不能让它变成 NULL 导致后续逻辑断裂，就得主动兜底。
比如统计每个用户订单总金额，但有些用户没下单——子查询返回 NULL，直接加总就会让整行变 NULL。
-
COALESCE((SELECT SUM(amount) FROM orders WHERE user_id = u.id), 0)：最常用，把NULL转成0 -
CASE WHEN (SELECT COUNT(*) FROM logs WHERE user_id = u.id) > 0 THEN 'active' ELSE 'inactive' END：适合分类判断，避免对NULL做比较 - 注意
COALESCE所有参数类型要兼容，否则可能报错，比如字符串和数字混用会触发隐式转换异常
EXISTS比子查询值更可靠地表达“存在性”
只要你想表达“这个用户有没有订单”“这个产品是否在促销表里”，就别用 (SELECT id FROM ...) IS NOT NULL，改用 EXISTS。
EXISTS 不关心子查询返回什么值，只看有没有行；它不返回 NULL，也不会因子查询无结果而让外层逻辑失效。
- 错误写法：
WHERE (SELECT 1 FROM discounts d WHERE d.product_id = p.id) IS NOT NULL - 正确写法：
WHERE EXISTS (SELECT 1 FROM discounts d WHERE d.product_id = p.id) -
NOT EXISTS同理，比NOT IN安全得多——后者遇到子查询含NULL会整个条件失效
NOT IN和NULL一起用等于自毁逻辑
col NOT IN (SELECT x FROM t) 看似简洁，但只要子查询结果里有一个 NULL，整个条件永远为 UNKNOWN，结果集必然为空——这是SQL三值逻辑最坑人的地方。
哪怕你肉眼确认子查询只返回几个ID，只要表里存在 x IS NULL 的记录，NOT IN 就不可信。
- 永远用
NOT EXISTS替代NOT IN做排除判断 - 如果非要用
NOT IN，必须加WHERE x IS NOT NULL过滤子查询：col NOT IN (SELECT x FROM t WHERE x IS NOT NULL) - 某些数据库（如PostgreSQL）对
NOT IN的NULL行为有优化，但别依赖——跨库迁移时大概率翻车
