在数据库开发中，对某一列的数值进行合计是最常见的需求之一，比如统计订单总金额、计算某个月的销量总和、汇总用户积分等。MySQL提供的SUM函数就是专门用来解决这类问题的聚合函数。它的用法看似简单，只需求某列的总和即可，但实际使用中涉及NULL值处理、分组统计、条件过滤、精度控制等多个细节点，稍不注意就会得到错误的结果。本文将系统地讲解SUM函数的语法、使用场景以及常见陷阱。
SUM函数的基本语法与执行原理
SUM是一个聚合函数，用来计算一组值中非NULL值的总和。它的基本语法形式如下：
SELECT SUM(column_name) FROM table_name WHERE condition;
执行时，MySQL会先根据WHERE条件筛选出符合条件的行，然后逐行读取指定列的值。如果某个值是NULL，SUM会自动跳过它，只对非NULL的数值累加。这一点和普通算术运算不同：在SQL中，NULL加上任何数结果都是NULL，但SUM函数内部做了特殊处理，直接忽略NULL，这一点在后面会展开说明。
下面通过一个订单表来演示基础用法。假设表结构如下：
CREATE TABLE orders (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT NOT NULL,
amount DECIMAL(10,2) NOT NULL,
status TINYINT DEFAULT 1, -- 1已支付 0未支付
created_at DATETIME
);
INSERT INTO orders (user_id, amount, status, created_at) VALUES
(1001, 250.00, 1, '2024-01-05 10:00:00'),
(1001, 89.50, 1, '2024-01-06 11:30:00'),
(1002, 320.00, 0, '2024-01-06 14:20:00'),
(1002, 158.00, 1, '2024-01-07 09:15:00'),
(1003, 66.00, 1, '2024-01-07 16:40:00');
如果要统计所有订单的总金额，直接这样写：
SELECT SUM(amount) AS total_amount FROM orders;
执行结果为883.50。这里给SUM的结果起了别名total_amount，这是良好的书写习惯，方便程序读取，也让查询结果的可读性更好。需要注意的是，SUM只能用于数值类型的列，如果对字符串列使用，MySQL会尝试将字符串转为数字再累加，转不成数字的按0处理，这种行为通常不是我们想要的，容易产生隐蔽的错误。
结合WHERE条件与GROUP BY的分组求和
单纯的整表求和在实际业务中并不多见，更多时候需要带条件过滤，或者按某个维度分组统计。带条件的求和很简单，比如只统计已支付订单的总额：
SELECT SUM(amount) AS paid_total FROM orders WHERE status = 1;
如果要统计每个用户的消费总额，就需要用到GROUP BY了。GROUP BY会按照指定的列将数据分成若干组，SUM则在每组内部分别求和：
SELECT user_id, SUM(amount) AS user_total FROM orders GROUP BY user_id;
查询结果中，user_id为1001的合计是339.50，1002的是478.00（包含未支付订单），1003的是66.00。这里有一个非常经典的陷阱：SELECT后面的非聚合列必须出现在GROUP BY子句中。比如写成SELECT user_id, status, SUM(amount) FROM orders GROUP BY user_id，在开启了ONLY_FULL_GROUP_BY模式（MySQL 5.7以上默认开启）时会直接报错，提示status列不在GROUP BY中。原因很简单，一个user_id可能对应多个不同的status值，MySQL不知道该返回哪一个，与其返回随机值，不如直接报错更安全。
分组统计还经常搭配HAVING使用。WHERE是在分组前过滤行，HAVING是在分组后过滤组。比如要找出消费总额超过200的用户：
SELECT user_id, SUM(amount) AS user_total FROM orders GROUP BY user_id HAVING SUM(amount) > 200;
如果把条件写进WHERE会怎样？WHERE SUM(amount) > 200会直接报语法错误，因为聚合函数不能出现在WHERE子句中，WHERE执行时数据还没有分组，聚合值根本不存在。理解SQL语句的逻辑执行顺序有助于记住这条规则：FROM、WHERE、GROUP BY、HAVING、SELECT、ORDER BY，聚合发生在分组之后。
NULL值处理与结果判空的注意事项
SUM对NULL的处理规则值得单独拿出来说。第一条规则：求和时会跳过NULL值。假设有一列数据为10、NULL、20，SUM的结果是30而不是NULL。第二条规则：如果参与求和的所有值都是NULL，或者结果集本身为空，SUM返回NULL而不是0。这一点在程序层面处理时要格外小心，比如用Java读取时直接给Double赋值会得到null，后续做加减运算就会抛出空指针异常。
来看一个空结果集的例子：
SELECT SUM(amount) AS total FROM orders WHERE created_at > '2030-01-01'; -- 返回结果：total 的值为 NULL，而不是 0
如果业务上希望空结果返回0，可以用IFNULL或COALESCE函数兜底：
SELECT IFNULL(SUM(amount), 0) AS total FROM orders WHERE created_at > '2030-01-01'; -- 返回结果：total 的值为 0
另一个容易出错的场景是条件写错导致的隐式问题。比如想统计状态为0和1的订单总额，有人会写成SUM(amount = 1)这种形式，实际含义是统计满足条件的行数（类似COUNT），而不是求和。正确做法是先写好WHERE或CASE WHEN，再套SUM。
高级用法：CASE WHEN条件求和与多表关联
报表开发中经常需要在一次查询里同时得到多个维度的合计，这时SUM配合CASE WHEN非常强大。比如一条SQL同时统计已支付和未支付的总额：
SELECT
SUM(CASE WHEN status = 1 THEN amount ELSE 0 END) AS paid_total,
SUM(CASE WHEN status = 0 THEN amount ELSE 0 END) AS unpaid_total
FROM orders;
这种写法只需要扫描一次表就能得到多组结果，比分别执行多条SQL效率高得多。CASE WHEN内部先判断条件，满足则返回amount参与求和，不满足返回0（注意这里用ELSE 0而不是ELSE NULL，因为NULL会被跳过，虽然结果数值一样，但语义上返回0更清晰，也便于后续嵌套计算）。
多表关联求和也是高频场景。假设有一张用户表users，需要查出每个用户的昵称和消费总额：
SELECT u.username, IFNULL(SUM(o.amount), 0) AS total_spent FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id, u.username;
这里必须用LEFT JOIN而不是INNER JOIN，否则从未下过订单的用户不会出现在结果里。LEFT JOIN后没有订单的用户对应o.amount为NULL，SUM的结果也是NULL，所以外面套一层IFNULL转成0，报表展示时就不会出现null字样。
金额求和的精度问题与性能建议
存储金额时如果用了FLOAT或DOUBLE类型，SUM求和可能出现精度偏差，比如累加一堆0.1之类的值，结果带出长长的一串小数。这是浮点数的二进制表示决定的，不是SUM函数的bug。涉及金额的列应该使用DECIMAL类型，它是精确的定点数，求和结果不会有误差。如果表已经用了FLOAT，可以在查询时用CAST转换：SUM(CAST(amount AS DECIMAL(10,2)))，但从根本上讲还是应该修改列类型。
性能方面，SUM本质上是全表或索引范围扫描后的聚合计算。当数据量很大且查询频繁时，建议注意几点：第一，WHERE条件尽量命中索引，让SUM只扫描必要的范围；第二，覆盖索引可以避免回表，比如对(status, amount)建联合索引，统计已支付总额时直接在索引上完成求和；第三，对于亿级数据的实时汇总，可以考虑用汇总表或中间件缓存结果，不必每次都现场计算。
总结一下，SUM函数的基本用法确实简单，但要用对用稳，关键是掌握NULL值返回规则、GROUP BY的约束、条件求和的写法以及金额精度控制这几个核心点。把这些细节理清楚之后，无论是日常的运营数据统计还是复杂的报表开发，都能够写出准确且高效的求和SQL。