标量子查询返回空集时结果为null，不报错但会污染计算；in/exists不受影响；ifnull可兜底但性能差且不适用多行；优先用left join+coalesce，注意类型一致；空集使in变false、not in恒unknown。
子查询返回空集时，外层查询直接变NULL
MySQL里，当SELECT子句中嵌套的标量子查询（即只返回一行一列）没查到数据，整个表达式结果就是NULL，不是报错，也不是跳过——这点常被误以为“没影响”，其实会悄悄污染计算和判断逻辑。
比如：SELECT id, (SELECT name FROM users WHERE id = orders.user_id) AS user_name FROM orders，只要某条orders记录的user_id在users表里不存在，user_name就变成NULL，后续用WHERE user_name = 'Alice'或CONCAT('Hi, ', user_name)都会出意料之外的结果。
- 标量子查询必须确保有且仅有一行，否则报错；空集是合法但易被忽视的
NULL来源 -
IN或EXISTS类子查询不受此影响——它们本就不依赖“值”，而是布尔语义 - 如果子查询可能为空，又想避免
NULL干扰后续拼接或比较，就得主动兜底
IFNULL()只能兜住标量子查询，不能替代LEFT JOIN
IFNULL()确实能给子查询结果设默认值，比如IFNULL((SELECT name FROM users WHERE id = orders.user_id), 'Unknown')，但它不改变执行计划：每次外层行都要单独跑一次子查询，N行订单就触发N次单行查找，性能比LEFT JOIN差一个数量级。
更关键的是，IFNULL()对多行子查询无效——如果子查询意外返回两行，MySQL直接报错Subquery returns more than 1 row，而IFNULL()根本没机会介入。
- 只适用于确定为标量（0或1行）的子查询场景，比如关联主键、唯一索引字段
- 别在子查询里写
LIMIT 1来“强行标量化”，这掩盖了数据异常（如脏数据导致重复匹配） - 若需关联字段+缺省值，优先用
LEFT JOIN ... ON ...+COALESCE(users.name, 'Unknown')，更清晰也更快
COALESCE比IFNULL更通用，但要注意类型隐式转换
COALESCE(a, b, c)按顺序取第一个非NULL值，支持任意多个参数，比IFNULL(a, b)灵活。但它的陷阱藏在类型上：所有参数会被强制转成“最高优先级类型”，比如COALESCE((SELECT id FROM users LIMIT 1), 'N/A')，如果id是INT，MySQL会把'N/A'转成0，最终返回0而非字符串。
- 确保所有
COALESCE参数类型一致，尤其子查询字段和缺省字面量 - 字符串缺省值配字符串字段，数字缺省值配数字字段，宁可显式
CAST('N/A' AS CHAR)也不依赖隐式转换 - 在
ORDER BY或GROUP BY里用COALESCE兜底时，注意排序依据变成转换后的类型，可能打乱预期顺序
空集子查询遇上聚合函数，结果可能完全消失
当子查询用于WHERE条件，比如WHERE status IN (SELECT code FROM status_whitelist)，如果status_whitelist表为空，整个IN表达式变成IN ()，MySQL判定为FALSE，导致外层查询结果为空——不是NULL，是彻底没数据。这和标量子查询的NULL行为完全不同，容易误判为“条件写错了”。
-
NOT IN (SELECT ...)更危险：只要子查询含任意NULL，整个表达式恒为UNKNOWN，结果集直接为空 - 确认子查询是否可能为空？用
EXISTS替代IN更安全，比如WHERE EXISTS (SELECT 1 FROM status_whitelist s WHERE s.code = orders.status) - 若必须用
IN且子查询可能空，提前用COUNT(*) > 0判断，或改用临时表预存有效值
空集处理最麻烦的地方不在语法，而在它不报错、不警告，只默默让数据“少一点”或“变奇怪”。上线前得专门构造空表、删掉关联记录这类边界 case 跑一遍查询结果对比。
