SUM()忽略NULL是标准行为，因NULL代表未知值不参与聚合输入；仅当整列全NULL或无匹配行时才返回NULL；COALESCE(SUM(col),0)先聚合后兜底，SUM(COALESCE(col,0))先逐行补零再求和，语义不同需按业务选择。
SUM() 忽略 NULL 是标准行为，不是 bug，也不是“跳过再补 0”——它根本没把 NULL 当作输入值。计算结果比预期小，大概率是因为部分行被逻辑剔除，而非函数出错。
为什么 SUM(amount) 返回的值比 Excel 加总少？
这不是数据库算错了，而是那些 amount IS NULL 的行压根没进聚合管道。SUM() 的输入集只包含非 NULL 值，相当于执行了隐式的 WHERE amount IS NOT NULL。
- 验证方法：
SELECT COUNT(*), COUNT(amount), COUNT(*) - COUNT(amount) AS null_count FROM orders—— 差值就是被忽略的行数 - 常见诱因：LEFT JOIN 后右表字段（如
coupon_discount）为 NULL，表示“未匹配”，但业务上应计为 0 - 错误直觉：“NULL 就是空，应该当 0 算” → 实际上，NULL 是“未知”，不是零、不是空字符串、也不是 false
SUM(COALESCE(col, 0)) 和 COALESCE(SUM(col), 0) 差在哪？
二者语义完全不同，混用会导致统计失真，必须按业务含义选：
-
SUM(COALESCE(col, 0))：先逐行把 NULL 补成 0，再求和 → 适合“每行都该计入，缺值即为 0”，例如库存表中qty为 NULL 表示“未录入 = 0 件” -
COALESCE(SUM(col), 0)：先聚合，若结果为空集或全 NULL 才兜底为 0 → 适合“整组无数据时显示 0”，例如某部门本月无销售记录，报表需填 0 而非留空 - 典型错误：
COALESCE(SUM(coupon_discount), 0)用于 LEFT JOIN 场景 → 没用券的订单仍被整行忽略，总和偏低
带运算的表达式（如 total - discount）为什么更危险？
问题不在 SUM()，而在 SQL 的三值逻辑：只要 total 或 discount 任一为 NULL，total - discount 整个表达式就变成 NULL，再喂给 SUM() 就被跳过。
- 错误写法：
SUM(total - discount)→ 第 4 行因discount为 NULL，差值变 NULL，该行彻底消失 - 正确写法：
SUM(COALESCE(total, 0) - COALESCE(discount, 0)) - MySQL 可简写为：
SUM(IFNULL(total, 0) - IFNULL(discount, 0))，但跨库建议统一用COALESCE - 关键提醒：先确认业务含义——
discount IS NULL真的是“没优惠”，还是“优惠金额待确认”？后者补 0 就歪曲事实
GROUP BY 分组后某组 SUM 返回 NULL 怎么办？
分组内所有值恰好都是 NULL 时，SUM(col) 仍返回 NULL。BI 工具、JSON 序列化、前端渲染常因此报错或显示异常。
- 不能只在最外层加
COALESCE，必须对每个分组聚合结果单独兜底 - 正确写法：
SELECT category, COALESCE(SUM(amount), 0) AS total_amount FROM products GROUP BY category - 窗口函数同理：
SUM(amount) OVER (PARTITION BY dept)也可能返回 NULL，需包一层COALESCE - 注意：如果大量 NULL 源于 ETL 漏写或录入失败，盲目
COALESCE会掩盖真实的数据质量问题
真正难处理的从来不是 NULL 本身，而是同一列里混着不同语义：有的 NULL 表示“未发生”，有的表示“不适用”，有的表示“录入失败”。这时候统一用 COALESCE(col, 0) 看似省事，实则可能让统计口径彻底失效。
