子查询返回NULL时WHERE条件失效，因= NULL结果为UNKNOWN而被过滤；应改用EXISTS、显式IS NOT NULL判断或LEFT JOIN替代，避免COALESCE误用及IN/NOT IN陷阱。
子查询返回 NULL 时 WHERE 条件失效
SQL 中用 WHERE col = (SELECT ...) 这种写法，一旦子查询没结果（返回 NULL），整行直接被过滤掉——不是因为值不匹配，而是因为 = NULL 永远是 UNKNOWN，而 WHERE 只认 TRUE。
常见错误现象：SELECT * FROM orders WHERE customer_id = (SELECT id FROM customers WHERE name = 'Alice')，如果 'Alice' 不存在，查不到任何记录，连空集提示都没有。
- 改用
IS NOT NULL显式判断子查询结果：WHERE (SELECT id FROM customers WHERE name = 'Alice') IS NOT NULL AND customer_id = (SELECT id FROM customers WHERE name = 'Alice') - 更稳妥的做法是把子查询提到
FROM或用EXISTS：WHERE EXISTS (SELECT 1 FROM customers c WHERE c.name = 'Alice' AND c.id = orders.customer_id) - 注意：重复写两次子查询可能触发两次执行，性能敏感场景优先选
EXISTS或JOIN
COALESCE 在嵌套子查询中防崩但不防逻辑错
COALESCE 能兜住 NULL，但它不会帮你修正业务逻辑。比如 WHERE customer_id = COALESCE((SELECT id FROM customers WHERE name = 'Alice'), -1)，表面上不报错，但如果表里根本没有 customer_id = -1 的数据，结果仍是空。
使用场景：你明确知道某个默认值在业务上是“安全占位符”，比如用 0 表示“未指定客户”，且主表中确实存在 customer_id = 0 的合法记录。
-
COALESCE参数类型必须兼容，否则报错：COALESCE((SELECT name FROM customers ...), 42)会失败（字符串 vs 整数） - 嵌套多层子查询时，
COALESCE只作用于最内层表达式，不能“跨层兜底” - 别用
COALESCE(subquery, 0) = 0当作“子查询无结果”的判断依据——万一真有id = 0的客户呢？
IN 子句里子查询返回 NULL 的陷阱
WHERE col IN (SELECT x FROM t WHERE ...) 遇到子查询返回 NULL，整个条件变成 UNKNOWN，该行被排除。这不是 bug，是 SQL 标准行为，但极难排查。
典型错误现象：明明子查询能查出几条非空值，但外层 IN 却一条不中；一查发现子查询里某条记录的 x 是 NULL，它混进了结果集。
- 加
WHERE x IS NOT NULL过滤子查询输出：WHERE col IN (SELECT x FROM t WHERE ... AND x IS NOT NULL) - 用
NOT IN更危险——只要子查询里有一个NULL，整个条件永远为FALSE，务必避免 - PostgreSQL 和 SQLite 支持
IN (...) OR (...) IS NULL写法绕过，但 MySQL 不支持，跨库慎用
用 LEFT JOIN 替代相关子查询更可控
当子查询只用来取一个关联字段（比如订单对应的客户名），硬写成 (SELECT name FROM customers c WHERE c.id = o.customer_id) 不仅难读，还容易因 NULL 导致聚合或排序异常。
LEFT JOIN 把空值显式暴露为 NULL 字段，后续处理更透明，也方便加 COALESCE 或条件过滤。
- 别忘了给
JOIN条件加索引，否则性能可能比子查询还差 - 如果子查询有聚合（如
MAX(created_at)），JOIN 后需用窗口函数或先聚合再 JOIN，不能直接套用 - MySQL 8.0+ 对相关子查询做了不少优化，但复杂嵌套下，执行计划仍可能退化，建议用
EXPLAIN看实际是否走索引
空值不是数据缺失，是 SQL 三值逻辑的主动参与者。写子查询时，与其赌它“不会为空”，不如一开始就决定 NULL 该怎么参与计算、怎么影响流程——这个决策点，往往比语法本身更重要。
