SUM返回NULL而非0是SQL标准行为，用于区分“无数据”和“数据为零”；仅当整列全为NULL或WHERE未匹配任何行时发生，需用COALESCE(SUM(col),0)显式转0。
为什么SUM返回NULL而不是0
执行 SUM() 后得到 NULL，不是语法错，而是数据本身没值：整列全为 NULL，或 WHERE 条件没匹配到任何行。比如查已取消订单总金额：SELECT SUM(amount) FROM orders WHERE status = 'cancelled'，当天若无取消单，结果就是 NULL。
应用层若直接判空或未处理，容易崩溃。必须显式转成 0：
-
COALESCE(SUM(amount), 0)—— 兼容性最好，MySQL、PostgreSQL、SQL Server 都支持 -
IFNULL(SUM(amount), 0)—— MySQL 专用，更简洁 - 别用
ISNULL()或NVL()混用，不同数据库函数名不通用
JOIN后SUM翻倍是怎么回事
不是函数错了，是 JOIN 展开了一对多关系。例如 1 条订单关联 3 条订单项，LEFT JOIN 后变成 3 行，SUM(amount) 就把同一笔订单的金额加了 3 次。
错误写法（表面合理，实际翻倍）：SELECT o.id, SUM(oi.amount) FROM orders o LEFT JOIN order_items oi ON oi.order_id = o.id GROUP BY o.id
正确做法是先聚合再关联：
- 子查询方式（兼容所有版本）：
(SELECT order_id, SUM(amount) AS total FROM order_items GROUP BY order_id)，再LEFT JOIN主表 - 窗口函数（MySQL 8.0+）：
SUM(oi.amount) OVER (PARTITION BY oi.order_id)，但必须加DISTINCT去重，否则仍会输出多行 - 避免在
JOIN后直接对明细字段做SUM + GROUP BY，除非你确认关联侧没有一对多
浮点数求和出现0.0000001这类误差
根本原因不是 SUM()，而是底层用 FLOAT 或 DOUBLE 存金额。二进制浮点表示无法精确存储十进制小数（如 0.1），累加后误差放大。
解决方案分两层：
- 建表时就用
DECIMAL(12,2)存金额，而非FLOAT - 查询时补救：
SUM(CAST(amount AS DECIMAL(12,2)))或ROUND(SUM(amount), 2) - 注意：
ROUND()是事后修形，不能解决中间计算溢出；CAST更治本，但需确认目标精度足够（比如大额汇总可能需要DECIMAL(18,2)）
GROUP BY字段漏写导致结果不可靠
MySQL 5.7+ 和 PostgreSQL/SQL Server 在严格模式下会报错：column must appear in the GROUP BY clause。但旧版 MySQL 5.6 允许“隐式分组”，行为不稳定——升级后突然失败。
典型陷阱：
- 写
SELECT user_id, name, SUM(amount) FROM orders GROUP BY user_id——name不在GROUP BY，结果取决于引擎随机选哪一行的name - 别用别名写
GROUP BY，如SELECT user_id AS uid ... GROUP BY uid会报错，必须写原始字段名user_id -
HAVING必须配合GROUP BY使用，且只能引用聚合结果或GROUP BY字段；WHERE不能用SUM()
最稳妥的做法：所有非聚合字段都明确出现在 GROUP BY 列表里，不依赖隐式行为，也不指望引擎“猜你想怎么分组”。
