SQL嵌套查询中怎样正确处理NULL值对结果集的影响
标量子查询无结果时外层表达式变为NULL而非报错；COALESCE须包裹整个子查询括号；WHERE中=子查询遇NULL导致行被过滤；NOT IN含NULL时恒为UNKNOWN；IS NULL不能安全判断子查询是否返回行。
标量子查询没结果时，外层表达式直接变成 NULL，不是报错，也不是跳过——这是 SQL 标准行为，但极易引发静默逻辑错误。
COALESCE 必须包裹整个子查询括号
子查询返回空集时，NULL 会“传染”到整个算术或字符串表达式。比如 price * (SELECT tax_rate FROM taxes WHERE id = 1)，只要子查询没查到行，结果就是 NULL，而不是你预期的原价或 0。
正确写法是把 COALESCE 紧贴子查询最外层括号：
- ✅
COALESCE((SELECT tax_rate FROM taxes WHERE id = 1), 0) - ❌
(SELECT COALESCE(tax_rate, 0) FROM taxes WHERE id = 1)（子查询仍可能返回空集，结果还是NULL） - ❌
COALESCE(SELECT tax_rate FROM taxes WHERE id = 1, 0)（语法错误，漏了外层括号）
WHERE 中用 = 子查询时，NULL 导致整行被过滤
WHERE customer_id = (SELECT id FROM customers WHERE name = 'Alice') 这种写法，一旦子查询无结果，= NULL 的逻辑值是 UNKNOWN，而 WHERE 只接受 TRUE，所以该行直接被丢弃，查不到任何提示。
更安全的替代方案：
- 用
EXISTS：WHERE EXISTS (SELECT 1 FROM customers c WHERE c.name = 'Alice' AND c.id = orders.customer_id) - 若坚持用标量子查询，得显式判断两次（不推荐，性能差）：
WHERE (SELECT id FROM customers WHERE name = 'Alice') IS NOT NULL AND customer_id = (SELECT id FROM customers WHERE name = 'Alice')
NOT IN 遇到子查询含 NULL 就失效
WHERE status NOT IN (SELECT status FROM status_ref) 看似想排除所有已知状态，但如果 status_ref.status 里有 NULL，整个条件恒为 UNKNOWN，结果就是查不到任何数据。
根本原因是三值逻辑：NOT IN (1, 2, NULL) 等价于 status != 1 AND status != 2 AND status != NULL，最后一项永远是 UNKNOWN。
正确写法：
- ✅
WHERE NOT EXISTS (SELECT 1 FROM status_ref s WHERE s.status = o.status) - ✅
WHERE status NOT IN (SELECT status FROM status_ref WHERE status IS NOT NULL)
IS NULL 不能用于判断子查询是否返回行
WHERE (SELECT id FROM admins WHERE admins.user_id = users.id) IS NULL 是危险写法：在 PostgreSQL 或 SQL Server 中会明确报错 subquery must return only one value；MySQL 某些模式下可能静默转为 NULL，但不可靠。
真正可控的做法：
- 强制标量：加
LIMIT 1+COALESCE或MAX()收束，如(SELECT COALESCE(MAX(id), 0) FROM admins WHERE admins.user_id = users.id LIMIT 1) - 改用
NOT EXISTS表达“不存在关联记录”的语义，语义清晰、跨库兼容 - 避免在
WHERE中直接嵌套未加约束的子查询，尤其涉及一对多关系时
最容易被忽略的点是：子查询本身是否返回 0 行，和子查询字段值是否为 NULL，这是两个完全不同的问题，但都导向同一个结果——外层逻辑崩坏。必须区分处理，不能靠经验猜测数据库行为。
