SUM(col)返回NULL而非0，是因为SQL标准规定：当所有参与计算的值均为NULL时结果为NULL；含NULL行会被自动跳过，但全NULL组无有效值可聚合。
SUM 函数不是万能求和工具，用错场景会返回 NULL 或漏统计——尤其当字段含 NULL、需要分组汇总、或涉及多表关联时。
为什么 SUM(col) 返回 NULL 而不是 0？
只要 col 在参与计算的任意一行中为 NULL，SUM() 会自动跳过该行；但如果所有行的 col 全是 NULL，结果就是 NULL，不是 0。
- 常见错误：前端直接渲染
SUM(amount)结果，遇到NULL显示为空或报错 - 安全写法：改用
SUM(COALESCE(amount, 0))或外层套COALESCE(SUM(amount), 0) - 注意：
COALESCE(SUM(amount), 0)只在整组无数据时兜底；若组内有值但全为NULL，仍得NULL，此时必须用前者
SUM 配合 GROUP BY 时，WHERE 和 HAVING 容易混淆
WHERE 过滤行，HAVING 过滤分组——这是执行顺序决定的，不是语义选择。
-
WHERE在分组前生效，比如WHERE status = 'paid'能减少参与SUM()计算的数据量 -
HAVING必须跟聚合结果打交道，例如HAVING SUM(amount) > 1000；写成WHERE SUM(amount) > 1000会直接报错ERROR: aggregate functions are not allowed in WHERE - 性能提示：优先用
WHERE缩小数据集，避免对大量无效行做分组和求和
JOIN 后 SUM 结果翻倍？检查关联关系是否一对多
一旦 LEFT JOIN 或 INNER JOIN 的右表存在一对多关系（如一个订单对应多条订单项），SUM() 就会把主表字段重复计算多次。
- 典型现象：查订单总金额，结果比实际高几倍
- 验证方法：先
SELECT order_id, COUNT(*)看右表每条主键匹配了多少行 - 解决路径：
– 方案一：子查询预聚合右表，再 JOIN（推荐）
– 方案二：用DISTINCT配合窗口函数（如SUM(DISTINCT order_amount)不适用，因 SUM 不支持 DISTINCT 作用于表达式；正确做法是SUM(DISTINCT order_id)也无意义，应改用子查询）
MySQL 8.0+ 与 PostgreSQL 中 SUM 的 NULL 处理一致，但精度陷阱不同
两者都遵循 SQL 标准：忽略 NULL 行，空集返回 NULL。但数值类型隐式转换可能埋雷。
- MySQL：若列是
VARCHAR存数字（如'12.5'），SUM()会尝试转为DOUBLE，遇到非数字字符串（如'N/A'）变成0，导致静默错误 - PostgreSQL：同场景直接报错
cannot cast type character varying to numeric，更严格 - 建议：求和前用
CAST(col AS NUMERIC)显式转换，并配合WHERE col ~ '^[0-9.]+$'（PostgreSQL）或REGEXP（MySQL）过滤脏数据
真正难的不是写出 SUM()，而是判断它当前“算的是什么”——是原始业务值，还是被 JOIN 放大后的幻影值，或是被隐式转换污染的近似值。每次加 SUM 前，先 SELECT * LIMIT 5 看一眼原始数据分布。
