标量子查询返回NULL时外层表达式整体变NULL，导致计算、报表、展示静默失效；应优先用LEFT JOIN+COALESCE或EXISTS替代，避免IFNULL硬兜底引发性能与逻辑风险。
标量子查询返回 NULL 时，不会报错，但会直接让外层表达式整体变 NULL——比如 price + (SELECT tax_rate FROM config)，只要子查询没结果，整列就是空，统计、报表、前端展示全崩。这不是性能问题，是逻辑污染。
标量子查询一返回NULL，外层计算就静默失效
标量子查询在 SELECT 列表里参与算术、字符串拼接或函数调用时，任一操作数为 NULL，结果必为 NULL。它不抛异常，也不跳过，而是“传染”整个表达式。
-
CONCAT('Order #', order_id, ' by ', (SELECT name FROM users WHERE id = orders.user_id))→ 某条订单的user_id不存在时，整字段为空字符串，不是'Order #123 by ' -
amount * (SELECT rate FROM exchange WHERE currency = 'USD')→ 子查询无匹配，结果为NULL，后续再COALESCE(..., 0)也救不回来，因为乘法已提前中断 - 调试时很难定位：你看到的是最终结果为空，但无法一眼判断是主表字段空、子查询没数据，还是中间某层
NULL被透传
别用IFNULL((SELECT ...), default)硬兜底
这种写法看似能防崩，实则埋雷：每行触发一次子查询，N 行就是 N 次全表扫描（尤其没索引时），性能断崖式下跌；更关键的是，它把“关联缺失”伪装成“有默认值”，掩盖了数据质量问题。
- 错误示例：
IFNULL((SELECT MAX(price) FROM products p WHERE p.category_id = c.id), 0)→ 每个分类都跑一遍MAX()，且把“该分类无商品”等同于“价格为 0” - 正确思路：先确认是否真需要标量。多数场景下，
LEFT JOIN+COALESCE更高效、语义更清：COALESCE(p.max_price, 0)，而p.max_price来自预聚合或关联子查询 - 若必须用标量（如配置项全局只有一行），加
LIMIT 1防多行，并用COALESCE包裹最内层：(SELECT COALESCE(MAX(value), 0.08) FROM config WHERE key = 'tax_rate' LIMIT 1)
WHERE中用标量子查询等值匹配？NULL会让条件永远不成立
WHERE col = (SELECT x FROM t WHERE y = ?) 看似简洁，但子查询返回 NULL 时，整个表达式是 UNKNOWN，被 WHERE 当作 FALSE 过滤掉——你查不到数据，连提示都没有。
- 典型现象：换一个参数能出结果，换回原参数就空；
EXPLAIN显示走了索引，但rows为 0 - 错误补救：
WHERE (SELECT x FROM t WHERE y = ?) IS NOT NULL AND col = (SELECT x FROM t WHERE y = ?)→ 子查询执行两次，性能翻倍 - 正确替代：
WHERE EXISTS (SELECT 1 FROM t WHERE y = ? AND x = col)，语义明确，且优化器通常能复用索引 - 如果业务上允许
col IS NULL也算匹配，显式写出：WHERE col = (SELECT x FROM t WHERE y = ?) OR (col IS NULL AND NOT EXISTS (SELECT 1 FROM t WHERE y = ?))
排查时先确认NULL来自哪一层
复杂查询中，NULL 可能来自原始字段、JOIN 丢失、子查询无结果，或聚合函数（如 AVG() 跳过 NULL 但分母变小）。不能只看最终结果，要分层验证。
- 第一步：单独执行标量子查询，确认它在不同参数下是否真返回
NULL，例如：SELECT (SELECT name FROM users WHERE id = 999) - 第二步：在主查询中把子查询拆成显式
LEFT JOIN，观察连接后行数是否突增/突减 —— 若LEFT JOIN后行数暴涨，大概率是子查询本应一对一，但实际一对多或条件写错 - 第三步：对关键字段补统计：
SELECT COUNT(*), COUNT(subquery_result), COUNT(*) - COUNT(subquery_result) AS null_count FROM (...)，快速定位空值比例
最易被忽略的是：标量子查询的执行时机依赖于外层行，它的 NULL 不是静态的，而是随主表每一行动态生成；一旦嵌套多层（如子查询里再套子查询），调试链路会指数级变长。优先用 JOIN 拉平结构，比层层 COALESCE 更可持续。
