标量子查询返回NULL时WHERE条件总不成立，因其等值比较结果为UNKNOWN而非TRUE，导致行被静默过滤；应使用COALESCE设默认值、EXISTS替代存在性判断，或在应用层处理空结果。
标量子查询返回 NULL 时，WHERE 条件为什么总不成立
标量子查询在结果为空时**必然返回 NULL**，而任何与 NULL 的等值比较（如 =、!=）都会得到 UNKNOWN，不是 TRUE。这意味着 WHERE (SELECT x FROM t WHERE cond) = 5 在子查询无结果时整行被过滤掉，不是“跳过”，而是“静默丢弃”。
常见错误现象：
- 明明主表有数据，但加了标量子查询后结果变空
- 用 IN 包裹标量子查询（如 WHERE col IN (SELECT ...)），误以为能兼容空集 —— 实际上这是相关子查询或集合操作，不是标量语义
- 标量子查询必须且只能返回 0 或 1 行、1 列；多于 1 行会直接报错
Subquery returns more than 1 row - 不要用
IS NULL去“兜底”判断——那是在检查子查询是否为空，不是处理业务逻辑 - 真正需要的是：把“空结果”映射为一个有意义的默认值，再参与比较
用 COALESCE 或 IFNULL 给空结果设默认值
这是最直接、跨数据库通用的做法：把标量子查询包进 COALESCE，让它在返回 NULL 时提供替代值。注意默认值类型需和子查询列类型兼容，否则可能触发隐式转换或报错。
SELECT * FROM orders o WHERE o.customer_id = COALESCE( (SELECT id FROM customers WHERE email = 'user@example.com'), -1 -- 假设 customer_id 是正整数，-1 是安全哨兵值 );
-
COALESCE是 SQL 标准函数，IFNULL（MySQL）、ISNULL（SQL Server）是方言，优先用COALESCE - 默认值选什么取决于业务：用
0、-1、''都可以，但要确保它在后续逻辑中不会意外匹配真实数据 - 如果子查询本身可能返回
NULL（而非空集），COALESCE同样生效 —— 它统一处理“空集”和“显式 NULL”两种情况
用 EXISTS 替代标量子查询做存在性判断
当你的目标只是“查某条记录是否存在”，而不是“取它的某个字段值”，就别用标量子查询。用 EXISTS 更清晰、更高效，且天然规避空集问题 —— 它只返回 TRUE/FALSE，没有 NULL 语义干扰。
SELECT * FROM products p WHERE EXISTS ( SELECT 1 FROM inventory i WHERE i.product_id = p.id AND i.qty > 0 );
-
EXISTS子查询里写SELECT 1是惯例，内容无关紧要，数据库不会真取数据 - 性能上，
EXISTS通常比标量子查询快，尤其在子查询表很大时，因为找到第一行就终止 - 不能用
EXISTS获取字段值，所以它只适用于“有没有”的场景，不适用于“取哪个值”的场景
在应用层处理空结果比硬塞 SQL 更可控
如果标量子查询嵌套深、逻辑复杂，或需要根据不同空值原因走不同分支（比如“用户不存在”和“用户被禁用”要分别提示），强行在 SQL 里用 CASE WHEN + COALESCE 拼逻辑，会让查询难以调试和维护。
更推荐做法：把标量子查询拆成独立查询，在应用代码里判断结果是否为空，再决定后续动作。
- 例如先执行
SELECT id FROM users WHERE email = ?，拿到None就直接返回 404，不继续查订单 - 避免在 SQL 中堆砌多层
COALESCE(COALESCE(...), ...)，可读性差，也难加日志定位哪一层空了 - ORM 用户注意：像 Django 的
.values_list('id', flat=True).first()或 SQLAlchemy 的scalars().one_or_none()天然返回None，比手写标量子查询更直观
实际写标量子查询时，最容易被忽略的是：它和 JOIN 的语义完全不同。前者是“对每行求一个值”，后者是“扩行”。空集在 JOIN 中表现为左表保留、右表字段为 NULL；在标量子查询中表现为整个表达式为 NULL —— 这个差异决定了你该用哪种结构，而不是想着怎么“修”标量结果。
