子查询返回null时where条件失效，因三值逻辑使表达式为unknown而被静默丢弃；应改用exists、显式判断is null或coalesce兜底。
子查询返回NULL时WHERE条件直接失效
当你写 WHERE col = (SELECT value FROM t WHERE id = 1)，而子查询结果是 NULL，整个表达式不会变成 FALSE，而是 UNKNOWN。SQL的WHERE只保留 TRUE 行，UNKNOWN 被静默丢弃——你查不到数据，不是逻辑写错，是三值逻辑在起作用。
常见现象：主表明明有匹配记录，但结果为空；换一个ID就能查出来，换回原ID就空；用 EXPLAIN 看执行计划也没报错，就是没数据。
- 别在
=、!=、>左右直接放标量子查询，尤其不能假设它“总会返回一行” - 想判断子查询是否返回值，用
IS NULL或IS NOT NULL显式包裹：WHERE (SELECT price FROM products WHERE id = 100) IS NOT NULL - 更推荐改写为
EXISTS（见下一条），语义更清晰，且不依赖返回值内容
用EXISTS替代标量子查询做存在性判断
EXISTS 不关心子查询返回什么，只看有没有行——它天然绕过NULL陷阱，也不会因子查询无结果导致外层逻辑断裂。
错误写法：WHERE (SELECT 1 FROM discounts d WHERE d.product_id = p.id) IS NOT NULL，一旦子查询没数据或返回NULL，整行就被过滤。
正确写法：WHERE EXISTS (SELECT 1 FROM discounts d WHERE d.product_id = p.id)，只要关联存在，就为TRUE。
-
NOT EXISTS同样安全，比NOT IN可靠得多 - 子查询里不用写具体字段，
SELECT 1或SELECT *都行，优化器会忽略投影 - 注意相关列名作用域：确保
p.id能被子查询正确引用，否则可能变成全表扫描
IN/NOT IN子查询含NULL时逻辑崩溃
col IN (SELECT x FROM t) 看似简单，但只要子查询结果里有一个 NULL，整个表达式就变成 UNKNOWN，这一行必然被WHERE过滤掉——不是漏掉某条记录，是整批数据消失。
典型翻车场景：SELECT * FROM orders WHERE status IN (SELECT code FROM status_ref)，而 status_ref.code 有NULL值。
- 最稳妥解法：显式排除NULL，
SELECT code FROM status_ref WHERE code IS NOT NULL - 更健壮解法：改用
EXISTS关联：EXISTS (SELECT 1 FROM status_ref s WHERE s.code = o.status) - 别信“我确认子查询没NULL”，表结构变更、历史数据残留、LEFT JOIN引入都可能悄悄带入NULL
标量子查询参与计算时必须COALESCE兜底
当子查询作为字段值参与运算（比如 SELECT amount + (SELECT tax_rate FROM config) FROM orders），只要子查询返回 NULL，整列结果就是 NULL，且不报错、不告警。
这会导致报表金额全空、统计指标归零、前端展示异常——问题难定位，因为SQL语法完全合法。
- 立刻加
COALESCE：amount + COALESCE((SELECT tax_rate FROM config), 0) - 类型要一致：
COALESCE((SELECT name FROM users WHERE id = 1), '')，字符串和数字混用会触发隐式转换失败 - 避免嵌套太深：
COALESCE(COALESCE(sub1, sub2), 0)不如把兜底逻辑提前到子查询内部
NULL在子查询里不报错、不警告，只悄悄让结果变空或变错。最容易被忽略的是：你以为子查询“应该有值”，其实它根本没查到，或者查到了NULL，而你的主查询逻辑完全没做防御。
