sum()自动忽略null，全列null时才返回null；需累计求和用sum()over()而非group by；count(*)与count(col)对null处理不同，影响平均值计算；性能优化需索引与覆盖索引。
用 SUM() 做基础求和时，NULL 值会自动被忽略
这是最常被误读的一点：很多人以为 SUM() 遇到 NULL 就报错或中断，其实它直接跳过。比如字段 amount 有值 100, NULL, 200，SUM(amount) 返回 300，不是 NULL。
但要注意：如果整列都是 NULL，SUM() 才返回 NULL（不是 0）。所以做展示前最好加 COALESCE(SUM(amount), 0)。
- 别在聚合前用
WHERE amount IS NOT NULL过滤——多余，SUM()本来就不理 NULL - 想把 NULL 当 0 算？得先用
IFNULL(amount, 0)或COALESCE(amount, 0)转换，再套SUM() -
SUM()对非数值类型会隐式转成 0（比如字符串'abc'→0），容易掩盖脏数据，建议提前校验类型
按分组累计求和要用 SUM() OVER()，不是 GROUP BY
GROUP BY 是“压缩”数据（每组一行），而累计求和需要“保留原行 + 加一列累加值”，必须用窗口函数。
比如查每日销售额并叠加计算到当天的总销售额：
SELECT date, sales, SUM(sales) OVER (ORDER BY date) AS cumsum FROM daily_sales;
常见错法是写成 SELECT date, sales, SUM(sales) FROM daily_sales GROUP BY date ORDER BY date——这只会返回每天单日值，没有“累计”效果。
- 没写
ORDER BY在OVER()里？结果顺序不确定，累计值可能乱序 - 想按用户分组内累计？写成
SUM(sales) OVER (PARTITION BY user_id ORDER BY date) - MySQL 8.0+ 才支持窗口函数；5.7 及更早版本只能用变量模拟，但并发下不可靠，不推荐
SUM() 和 COUNT() 别混用：它们对 NULL 的处理逻辑不同
COUNT(column) 统计非 NULL 行数，COUNT(*) 统计所有行——这个差异直接影响“平均值”类计算是否准确。
例如算平均订单金额：SUM(amount) / COUNT(*) 和 SUM(amount) / COUNT(amount) 结果可能差很多。
- 如果
amount有 20% 是 NULL，COUNT(*)分母偏大，算出的平均值偏小 - 业务上想表达“所有订单的平均金额”，该用
COUNT(*)；想表达“有金额记录的订单的平均值”，才用COUNT(amount) - 更安全的写法是明确语义：
SUM(amount) / NULLIF(COUNT(amount), 0)，避免除零错误
大表上 SUM() 慢？先看执行计划里有没有走索引
SUM() 本身不慢，慢是因为全表扫描。如果只对某条件求和（比如 SUM(amount) WHERE status = 'paid'），而 status 没索引，就会扫全表。
另外注意：普通二级索引不包含主键以外的字段，如果 amount 不在索引里，即使 WHERE 走了索引，仍需回表取值，I/O 成瓶颈。
- 高频聚合场景，考虑建覆盖索引，例如
INDEX idx_status_amount (status, amount) -
SUM()结果是单值，MySQL 通常不会用到ORDER BY或LIMIT优化，别白加 - 实时性要求不高？可把结果物化到汇总表，用定时任务更新，比每次
SUM()快得多
累计计算真正麻烦的不是语法，而是边界：空数据、时序错乱、并发更新导致的重复或遗漏——这些没法靠一个函数解决，得结合业务约束设计存储结构。
