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，这是两个完全不同的问题，但都导向同一个结果——外层逻辑崩坏。必须区分处理，不能靠经验猜测数据库行为。