SUM遇NULL跳过是标准行为而非bug；需据业务语义区分COALESCE(SUM(col),0)与SUM(COALESCE(col,0))，含NULL的标量运算会导致整行被忽略，NULL本质是数据语义问题。
SUM 遇到 NULL 值时不会报错，也不会当 0 算，而是直接跳过该行——这本身是标准行为，不是 bug。但多数业务场景下，你真正需要的不是“跳过”，而是“当作 0 加进去”或“没数据时显示 0”，这两者必须区分清楚，否则统计结果会悄悄出错。
为什么 SUM(col) 返回 NULL 而不是 0
这不是数据库“没处理好”，而是 SQL 标准定义：当聚合输入为空集（比如 WHERE 没匹配到任何行）或所有值都是 NULL 时，SUM 必须返回 NULL。它代表“无定义结果”，不是“零”。
- 常见错误现象：
SELECT SUM(amount) FROM orders WHERE status = 'cancelled'返回NULL，但程序里直接用getInt()取值会抛SQLException - 验证方法：
SELECT COUNT(*), COUNT(amount), SUM(amount) FROM orders—— 如果前两列数字不等，说明有amount IS NULL的行被跳过了 - 注意：
COUNT(*)统计所有行，COUNT(amount)和SUM(amount)都只看amount IS NOT NULL的行
COALESCE(SUM(col), 0) 和 SUM(COALESCE(col, 0)) 语义完全不同
选错一个，业务指标就偏了。关键看“NULL 在业务上代表什么”：
-
COALESCE(SUM(col), 0)：先聚合，再兜底。适用于“整组无数据时填 0”，比如某销售员本月无订单，报表希望显示 “0 元” 而非留空 -
SUM(COALESCE(col, 0))：先逐行补零，再求和。适用于“每行都该计入，缺值即为 0”，比如库存表中qty为NULL表示“未录入”，业务约定就是 0 件 - LEFT JOIN 后的字段（如
coupon_discount）天然含NULL，表示“没用券”，必须用SUM(COALESCE(coupon_discount, 0))；若误用COALESCE(SUM(coupon_discount), 0)，会把整个用户组抹掉
含运算的表达式里 NULL 更危险：比如 SUM(total - discount)
问题不在 SUM，而在减法本身——SQL 中任意含 NULL 的标量运算（+、-、*、/）结果必为 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 就歪曲事实
最常被忽略的一点：NULL 处理不是纯技术问题，而是数据语义问题。同一张表里，有些 NULL 表示“未发生”，有些表示“未知”，有些甚至表示“不适用”。不厘清这个，光套函数只会让错误更隐蔽。
