sum() 返回 null 而非 0 是因空结果集或字段含 null，需用 coalesce(sum(amount), 0) 处理；金额字段应为 decimal 类型，varchar 需清洗后转换；group by 必须包含所有非聚合字段或配合聚合函数；大表聚合应优化索引或使用物化汇总。
直接用 SUM() 就能算金额合计，但结果为 NULL、小数精度丢失、或漏掉 WHERE 条件导致数据不准，才是真问题。
为什么 SUM() 返回 NULL 而不是 0？
当查询结果为空（比如没匹配到任何行），SUM() 默认返回 NULL，不是 0 —— 这在报表展示或后续计算中容易引发空值错误。
- 用
COALESCE(SUM(amount), 0)显式转成0，更安全 - 别依赖数据库默认行为：MySQL 5.7+ 在
sql_mode含STRICT_TRANS_TABLES时对空组更敏感；PostgreSQL 始终返回NULL - 如果字段本身含
NULL，SUM()会自动跳过（不报错也不计入），但得确认业务上是否允许忽略这些记录
金额列是 VARCHAR 或带符号/逗号怎么办？
直接 SUM(amount) 会失败或静默转成 0（如 MySQL 把 '¥1,234.50' 当作 0），必须先清洗。
- MySQL：用
REPLACE(REPLACE(amount, '¥', ''), ',', '')去符号和千分位，再CAST(... AS DECIMAL(12,2)) - PostgreSQL：用
REGEXP_REPLACE(amount, '[^0-9.-]', '', 'g')提纯数字字符串，再::DECIMAL强转 - 强烈建议：金额字段类型应为
DECIMAL或NUMERIC，而非字符串 —— 否则索引失效、排序错乱、四舍五入不可控
按用户/日期分组求合计时，GROUP BY 漏写字段会怎样？
比如想查每个用户的订单金额总和，却只写 GROUP BY user_id，但 SELECT 里又写了 username —— 在严格模式下（如 MySQL 8.0+ 默认）会报错：Expression #2 of SELECT list is not in GROUP BY clause。
- 要么把所有非聚合字段都放进
GROUP BY（如GROUP BY user_id, username） - 要么用聚合函数包裹，如
MAX(username)（前提是user_id和username一一对应） - 别关
sql_mode图省事：掩盖逻辑缺陷，上线后可能因版本升级突然崩
大表上 SUM() 很慢？先看执行计划
全表扫描 + 聚合 = I/O 和 CPU 双重压力。尤其当加了 WHERE 却没走索引时，性能断崖下跌。
- 用
EXPLAIN看type是否为ALL（全表扫描）、key是否用了索引 - 金额字段单独建索引意义不大，但组合索引如
(status, created_at, amount)可覆盖常见筛选+聚合场景 - 如果只是定期统计，考虑物化汇总表或定时写入
summary表，避免每次实时计算
最常被忽略的是字段类型和空值处理——不是语法不会写，而是没意识到原始数据质量已经让 SUM() 失效了。
