sum()返回null是sql标准行为，用于区分“无数据”和“数据为零”，需据空结果集、字段null或运算null等不同场景分别用coalesce、left join或类型修正处理。

为什么SUM()返回NULL而不是0

SUM()返回NULL不是bug，是SQL标准行为：空结果集（没匹配到任何行）或整列全为NULL时，它必须返回NULL，不能擅自变成0。这是为了区分“没有数据”和“数据明确为零”两种语义。比如统计某天订单总额，没交易就该是NULL；但用户账户余额字段为NULL，大概率是ETL异常，不该默认当0算。

空结果集 vs 字段本身为NULL，处理方式完全不同

看到SUM()返回NULL，先别急着套COALESCE()，得先定位来源：

• WHERE条件没命中任何行 → 用COALESCE(SUM(col), 0)兜底最直接
• col字段本身大量为NULL，但业务上“未填写=0” → 应该先用COALESCE(col, 0)再聚合：SUM(COALESCE(col, 0))
• 分组后某组没数据（比如某用户没订单），整行直接不出现 → 这不是SUM()的问题，得用LEFT JOIN补全维度，或改用条件聚合：SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END)

多个字段参与运算时，NULL会“传染”

写SUM(total_amount - freeze_amount)这类表达式时，只要任一字段为NULL，减法结果就是NULL，整行被SUM()跳过——但你本意可能是“冻结金额为空就当作0”。这不是SUM()的错，而是SQL三值逻辑的必然结果。

正确做法是在运算层拦截：

• MySQL可用：SUM(IFNULL(total_amount, 0) - IFNULL(freeze_amount, 0))
• 跨库兼容写法：SUM(COALESCE(total_amount, 0) - COALESCE(freeze_amount, 0))

金额类求和必须防浮点误差，别只盯NULL

即使你把NULL全转成0，如果字段类型是FLOAT或REAL，SUM()结果仍可能有精度偏差，比如SUM(0.1::real)重复10次≠1.0。这不是NULL问题，但常被一起忽略：

• 金额字段建表时务必用DECIMAL(p,s)，例如amount DECIMAL(12,2)
• 已有FLOAT字段又不能改表？临时修复可用ROUND(SUM(col), 2)，但只是掩盖，不治本
• 前端接API时，如果后端返回null或0.0000001，JS都可能崩——所以NULL处理和类型定义得同步做