IN子查询返回空集时整行被过滤，因表达式求值为FALSE；=子查询为空或为NULL时求值为UNKNOWN，两者均被WHERE排除，这是SQL三值逻辑的必然行为。
子查询结果为空时，IN 返回 FALSE，= 返回 UNKNOWN，两者都会被 WHERE 过滤掉——这不是 bug，是 SQL 三值逻辑的必然行为。
IN 子查询返回空集时为什么整条 WHERE 失效
IN 右侧子查询若一行都不返回（即空集），整个表达式求值为 FALSE，不是 NULL，也不是“不匹配”，而是明确的假值。所以该行直接被 WHERE 拒绝。
- 现象：你确认主表有数据，也确认子查询逻辑没错，但结果始终为空 → 先查
SELECT COUNT(*) FROM ...确认子查询是否真返回了行 - 常见场景：
WHERE user_id IN (SELECT user_id FROM orders WHERE status = 'paid')，但当前没有已支付订单 → 子查询空，主查询全空 - 别指望
DISTINCT或COALESCE救这个：空集就是空集，加DISTINCT不会变出一行；COALESCE((SELECT ...), 0)仅适用于标量子查询（=场景），不能用于IN - 如果业务上“没匹配到”是合法状态（比如查“有付费记录的用户”），那就接受空结果；如果想查“所有用户，标记是否有付费”，就得改用
LEFT JOIN或EXISTS+CASE
= 子查询返回 NULL 或空集时为什么查不到数据
标量子查询（即预期只返回 0 或 1 行、1 列）若返回空集，结果为 NULL；若返回 NULL 值，结果也是 NULL。而 col = NULL 永远是 UNKNOWN，不会进 WHERE。
- 错误写法：
WHERE price = (SELECT MAX(price) FROM products WHERE category = 'book')，但 category='book' 的记录不存在 → 子查询空 → 整个等式为UNKNOWN→ 行被过滤 - 正确兜底：
WHERE price = COALESCE((SELECT MAX(price) FROM products WHERE category = 'book'), -1)，前提是-1不在合法 price 范围内 - 更安全的替代：
WHERE EXISTS (SELECT 1 FROM products p2 WHERE p2.category = 'book' AND p2.price = p.price)，它不依赖值比较，只看是否存在关联行 - 注意：
IS NULL和IS NOT NULL才能安全判断子查询结果是否为空，例如WHERE (SELECT ... ) IS NOT NULL
NOT IN 遇到空集或 NULL 更危险
NOT IN 在子查询为空时返回 TRUE（可接受），但只要子查询结果里含一个 NULL，整个表达式立刻变成 UNKNOWN，结果集必然为空——这是最隐蔽的坑。
- 典型翻车：
SELECT * FROM users WHERE id NOT IN (SELECT user_id FROM orders)，而orders.user_id允许为NULL→ 即便 orders 里有 100 万个非空 user_id，只要有一条user_id IS NULL，结果就全空 - 不要用
WHERE user_id IS NOT NULL临时补救：这只能滤掉子查询里的 NULL，但无法解决语义问题；且容易漏掉其他脏数据 - 唯一可靠解法：
WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)，它天然跳过 NULL 关联，逻辑清晰，性能通常更好 - 某些数据库（如 PostgreSQL）在
NOT IN中遇到空子查询会报 warning，MySQL 则静默失败，别依赖报错来发现
真正难处理的不是空集本身，而是空集和 NULL 混在一起时的三值逻辑叠加效应——尤其是 NOT IN 和多层嵌套子查询里，一个没显式排除的 NULL 就能让整个条件失效，且很难通过肉眼 SQL 检查出来。
