先说一个很多开发者踩过坑的核心问题：标量子查询如果没返回数据，外层表达式并不会报错，也不会直接跳过，而是默默返回一个 NULL。这其实是 SQL 标准规定的行为，但恰恰因为“不报错”，它反而成为最难排查的静默逻辑错误之一。
比如你写了一句 price * (SELECT tax_rate FROM taxes WHERE id = 1)，如果子查询没查到行，结果就变成 NULL，而不是你预想的原价，更不是 0。这就很要命了。
要避免这种“感染”，最保险的做法是：COALESCE 必须包裹整个子查询括号。
COALESCE 必须包裹整个子查询括号
一旦子查询没找到行，NULL 就会“传染”到整个算术或字符串表达式。正确的写法是：从最外层把整个子查询结果兜住，比如：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 在 SQL 里不是 FALSE，而是 UNKNOWN。而 WHERE 只认 TRUE，结果就是该行直接被丢弃，而且不会给你任何提示。
更稳妥的替代方案：直接用 EXISTS 来改写逻辑，比如 WHERE EXISTS (SELECT 1 FROM customers c WHERE c.name = 'Alice' AND c.id = orders.customer_id)。如果非要坚持用标量子查询，那就得先做一次非空判断（但性能不好，一般不推荐）。
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 某些模式下可能不会报错，但处理结果也不靠谱。
真正可控的做法是：
- 强制标量化：加上
LIMIT 1配合COALESCE或MAX()，比如(SELECT COALESCE(MAX(id), 0) FROM admins WHERE admins.user_id = users.id LIMIT 1) - 直接用
NOT EXISTS表达“不存在关联记录”的语义，更清晰、跨库也更兼容 - 尽量避免在
WHERE中直接嵌套未加约束的子查询，尤其是一对多关系时
最容易忽略的一点是：子查询是否返回 0 行，和子查询字段值是否为 NULL，是两件完全不同的事。但它们最终都会导致同一个后果——外层逻辑崩坏。必须区分对待，不能靠经验猜测数据库行为。
