IN子查询遇NULL返回UNKNOWN导致整行被过滤，NOT IN更危险会因一个NULL使结果全空，应优先用NOT EXISTS替代；COALESCE须作用于整个子查询外层。
IN子查询遇到NULL直接变UNKNOWN，整行被过滤
只要子查询结果里带一个NULL，IN表达式就不再返回TRUE或FALSE，而是UNKNOWN。而WHERE只保留TRUE的行，UNKNOWN和FALSE一样被丢弃——不是漏掉NULL本身，是所有匹配都失效。
比如id IN (1, NULL)，哪怕id = 1，整个判断仍是UNKNOWN，这行直接消失。
- 常见错误写法：
SELECT * FROM users WHERE id IN (SELECT user_id FROM orders)，而orders.user_id有脏数据NULL - 查不到数据时别急着改条件，先
SELECT COUNT(*) FROM orders WHERE user_id IS NULL确认是否存在NULL - MySQL、PostgreSQL、SQL Server 行为一致，这不是数据库差异，是SQL标准的三值逻辑
COALESCE必须包在子查询外面，不能塞进里面
COALESCE或IFNULL要作用于整个子查询表达式，而不是子查询内部的聚合或字段。子查询没结果时，整个表达式求值为NULL；如果只在子查询里写COALESCE(SUM(...), 0)，那当WHERE完全不匹配、压根没生成任何行时，COALESCE根本不会执行。
- 错误：
SET x = (SELECT COALESCE(SUM(y), 0) FROM t WHERE ...)—— 子查询空集时仍返回NULL - 正确：
SET x = COALESCE((SELECT SUM(y) FROM t WHERE ...), 0) - UPDATE语句中尤其容易踩坑，因为
SET右侧直接接收子查询结果，空集=赋NULL
NOT IN比IN更危险：一个NULL就让结果全空
NOT IN等价于一连串AND判断：id != a AND id != b AND id != NULL。只要其中一项是UNKNOWN（比如id != NULL），整个表达式就是UNKNOWN，该行被过滤。所以哪怕子查询只返回一个NULL，NOT IN就永远查不到任何数据。
- 典型场景：查“未下单用户”，但订单表
user_id有NULL，结果空集 - 不要用
NOT IN (SELECT ... WHERE col IS NOT NULL)来绕，这治标不治本，且易遗漏 - 优先换用
NOT EXISTS：WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id)，它天然跳过NULL比较
EXISTS比IN更稳，也更适合关联逻辑
EXISTS不依赖值比较，只关心子查询是否能“找到一行”。它自动忽略NULL参与的关联条件，也不受子查询结果集中是否有NULL影响。而且优化器通常能对EXISTS中的关联字段下推索引，性能往往更好。
-
IN适合静态列表或确定无NULL的子查询，如id IN (1,2,3) -
EXISTS适合“是否存在某类记录”这类语义，尤其是涉及多表关联时 - 注意写法：
EXISTS (SELECT 1 FROM t WHERE t.x = outer.y)，别漏掉关联条件，否则变成恒真
真正麻烦的不是NULL本身，而是它让逻辑从二值变成三值，而大多数人写SQL时默认按二值思维推理。一旦子查询可能为空或含NULL，就得主动处理——要么过滤，要么换结构，不能靠“应该没问题”蒙混过关。
