COALESCE(SUM(), 0)是最直接的兜底写法，用于将空结果集产生的NULL转为0；需置于聚合函数外层，类型必须一致，且不可用IFNULL替代。
COALESCE(SUM(), 0) 是最直接的兜底写法
SUM()、AVG()、MAX()、MIN() 在空结果集（即没匹配到任何行）时返回 NULL，这是 SQL 标准行为，不是 bug。但如果你的业务逻辑期望一个数字（比如报表展示、Java int 字段映射、前端加总计算），直接用 SUM(amount) 就可能崩：数值运算报错、MyBatis 映射失败、前端显示空白。
正确做法是在聚合函数外层立刻套一层 COALESCE()：
SELECT COALESCE(SUM(amount), 0) FROM orders WHERE status = 'paid' AND created_at > '2026-05-01';
-
COALESCE()按顺序取第一个非NULL值，参数类型必须一致；SUM()返回DECIMAL或INT，所以第二个参数得是数字字面量（如0），不能写'0' - 别用
IFNULL()替代——它只支持两个参数、MySQL 专属，且在跨数据库迁移时容易出问题 - 如果字段本身含
NULL（比如amount列有空值），SUM()会自动忽略它们，不影响结果；你只需处理“空结果集”这一种NULL来源
分组统计时，COALESCE 必须放在聚合函数外层
在 GROUP BY 场景下，COALESCE 的位置极易写错。错误示范：COALESCE(amount, 0) 放在 SUM() 里面，这只能处理单行 amount 为 NULL 的情况，对整个分组为空仍无效。
正确结构是：
SELECT category, COALESCE(SUM(amount), 0) AS total_amount FROM sales WHERE month = '2026-04' GROUP BY category;
- 每个分组若无数据，
SUM()先产出NULL，再由外层COALESCE转成0 - 如果用了
LEFT JOIN关联后求和，也要确保COALESCE包裹的是最终聚合结果，而不是中间字段 - 注意：
COUNT(*)不会返回NULL（空组返回0），无需COALESCE；但COUNT(column)若列全为NULL，也返回0，同样不触发NULL问题
嵌套子查询里 COALESCE 必须在外层，且类型要对齐
标量子查询（返回一行一列）在查不到数据时，整个子表达式就是 NULL。比如：(SELECT SUM(revenue) FROM monthly_report WHERE year = 2026 AND month = 5)，若该月没数据，结果就是 NULL，直接参与外层计算会污染逻辑。
这时候不能把 COALESCE 写进子查询内部（如 (SELECT COALESCE(SUM(...), 0) FROM ...)），而必须让外层承接并转换：
SELECT id, name, COALESCE((SELECT SUM(revenue) FROM monthly_report r WHERE r.dept_id = d.id), 0) AS dept_revenue FROM departments d;
- 子查询本身仍是标量，
COALESCE在外层包裹整个子查询表达式，语义清晰 - 所有参数类型必须兼容：若子查询返回
DECIMAL(10,2)，缺省值就得是0.00，写0通常可隐式转换，但显式写0.00更稳妥 - 避免在子查询里用
LIMIT 1强行“保命”，这掩盖了本应报警的数据异常（例如重复主键或脏关联）
COALESCE 类型隐式转换是隐形陷阱
COALESCE(a, b, c) 会把所有参数转成“最高优先级类型”。常见翻车点：
SELECT COALESCE((SELECT id FROM users WHERE name = 'Alice'), 'N/A') -- ❌ id 是 INT，'N/A' 被转成 0
结果不是字符串 'N/A'，而是整数 0，因为 MySQL 把字符串强制转成了数字。
- 字符串字段配字符串缺省值：
COALESCE((SELECT name FROM users ...), 'Unknown') - 数字字段配数字缺省值：
COALESCE((SELECT score FROM exams ...), 0)或0.0 - 不确定类型时，用
CAST显式声明：COALESCE((SELECT id FROM ...), CAST('N/A' AS CHAR)) - 在
ORDER BY中用COALESCE排序时，排序依据变成转换后的类型，可能导致0和'N/A'混排，需提前确认排序意图
空结果集返回 NULL 是 SQL 的确定性行为，不是数据缺陷；真正危险的是默认放任它穿透到应用层。每一次写 SUM、AVG、子查询，都该条件反射加一层 COALESCE —— 不是因为怕错，而是因为不加，就等于把边界 case 交给下游去猜。
