sql中sum函数怎么用

上周 看SQL的SUM函数用法。

挺常用的。

SUM(salary) 直接求和。

employees表。

department='Sales' 过滤条件。

SUM(salary) AS total_salary 结果别名。

department, SUM(salary) AS total_salary 分组计算。

SUM(salary) + SUM(bonus) AS total_compensation 多列加和。

非数字列？ 忽略的。

NULL值？ 跳过的。

AVG(), COUNT() 一起用。

大表SUM() WHERE条件优化。

CASE WHEN status='completed' THEN amount ELSE 0 END 条件求和。

department, SUM(salary) HAVING过滤。

SUM(salary) > 1 00000 分组筛选。

组合用起来灵活。
算了。

SQL中SUM函数如何计算总和_SUM函数计算总和的正确用法

记得有一次，我帮一家电商网站优化订单统计功能。
那时候，系统里的订单数据量已经达到了几十万条，每次统计订单总额都要花上好几分钟。
我一看，问题就出在SUM函数的使用上。
我试着在amount列上加了索引，然后又用了WHERE子句筛选了特定时间段的数据，这样一来，查询时间就缩短到了几秒钟。
但后来我又发现，有些订单因为操作失误，金额字段是空的，这导致SUM函数返回了NULL。
于是我又在SQL语句里加入了COALESCE函数，确保了即使有些数据是NULL，也能返回一个默认值0。
这个过程让我深刻体会到，使用SUM函数时，不仅要关注效率，还得考虑数据的完整性和准确性。
等等，还有个事，我突然想到，如果数据量继续增长，可能还需要考虑使用物化视图来优化性能。
不过，这个方法在当前情况下可能有点过早。

SQL中累计求和与滑动求和函数sum() over()用法

哎哟，咱们聊聊SQL里的sum()函数吧，这玩意儿可厉害了，有个扩展功能叫sum()over()，它有三种主要用法，分别是分组求和、累计求和和滑动求和。
咱们得找个实例来好好看看它是怎么玩的。

先说个例子，有个数据表叫dws_js_team_gmv，里面有几个字段：团队名、月份和成交额。
咱们就用这个表来说事儿。

第一个需求，得计算每个销售团队的年累计成交额，还得知道这累计额占整个团队累计成交额的百分比。
这事儿得用分组求和，还得保留当前行数。
看看这SQL代码：
sql SELECT 团队名, 月份, 成交额, SUM(成交额) OVER (PARTITION BY 团队名 ORDER BY 月份) AS 年累计成交额, (SUM(成交额) OVER (PARTITION BY 团队名 ORDER BY 月份)
LAG(SUM(成交额) OVER (PARTITION BY 团队名 ORDER BY 月份), 1 ) OVER (PARTITION BY 团队名)) / SUM(成交额) OVER (PARTITION BY 团队名) AS 占比 FROM dws_js_team_gmv
这代码跑出来，咱们就能看到每个团队的年累计成交额和占比了。

第二个需求，得逐月累计业绩，从1 月开始。
这事儿也得分组求和，还得保留当前行数。
代码如下：
sql SELECT 团队名, 月份, 成交额, SUM(成交额) OVER (PARTITION BY 团队名 ORDER BY 月份) AS 累计成交额 FROM dws_js_team_gmv
这代码一跑，咱们就能看到从1 月开始到当前月份的累计成交额了。

第三个需求，得看近3 个月的累计业绩，包括统计月。
这涉及到滑动求和，咱们得用window函数over()设置滑动范围，比如从当前行前2 行到当前行。
代码示例如下：
sql SELECT 团队名, 月份, 成交额, SUM(成交额) OVER (PARTITION BY 团队名 ORDER BY 月份 ROWS BETWEEN 2 PRECEDING AND 1 PRECEDING) AS 近3 个月累计业绩 FROM dws_js_team_gmv
对于不包含统计月的近3 个月累计业绩，有三种处理方法。
第一种是减去统计月的值，计算近4 个月的滑动求和；第二种是调整滑动区间为3 个前一月到前两个前一月；第三种是调整为3 个前一月到后一个前一月。
这些方法都能用不同的rangebetween来设置。

这三种SQL代码展示了sum()over()函数在不同场景下的应用，帮助我们灵活处理累计和滑动求和需求。
说实话，我当时也没想明白这玩意儿，但用实例一看，就明白了。

在sql中 sum(case when ) 和 case when sum() 区别

哈，你这描述有点问题啊，让我帮你捋捋清楚。
最近在帮团队做SQL培训，刚好碰到过这种混淆，我给你讲讲我的理解。

先说SUM(CASE WHEN ... END)这个写法。
你举的例子其实是对的，这是标准用法。
比如去年我在北京某公司项目里统计过2 02 3 年各部门入职人数，就是这种写法。
关键点在于：
sql SELECT SUBSTR(to_char(hiredate, 'yyyy'), 1 , 4 ) AS year, COUNT() AS total_count, SUM(CASE WHEN deptno = '1 0' THEN 1 ELSE 0 END) AS dept1 0, SUM(CASE WHEN deptno = '2 0' THEN 1 ELSE 0 END) AS dept2 0 FROM emp GROUP BY SUBSTR(to_char(hiredate, 'yyyy'), 1 , 4 )
这里CASE WHEN是作为条件表达式嵌入到SUM()里的，它会对每个部门做独立计数，最后用SUM()聚合。
这种写法的好处是： 1 . 逻辑清晰，每个部门的条件判断直接写在列定义里 2 . 性能通常不错，因为数据库能优化CASE和SUM的组合 3 . 完美支持分组统计，deptno必须出现在GROUP BY里
然后你说的CASE WHEN SUM()这种写法...我有点懵。
我查了Oracle文档，确实没有这种语法。
你是不是把CASE WHEN和CASE表达式搞混了？
正确的"嵌套式"写法应该是这种： sql SELECT SUBSTR(to_char(hiredate, 'yyyy'), 1 , 4 ) AS year, COUNT() AS total_count, CASE WHEN deptno = '1 0' THEN COUNT() WHEN deptno = '2 0' THEN COUNT() ELSE 0 END AS special_count FROM emp GROUP BY SUBSTR(to_char(hiredate, 'yyyy'), 1 , 4 )
这里把COUNT()整个包在CASE WHEN里，然后外面再套个SUM()。
这种写法在SQL Server里更常见，但用起来要小心，因为如果CASE里引用了GROUP BY之外的列，会导致错误。

总结下我的看法： 1 . 你描述的SUM(CASE WHEN ... END)是正确的、常用的分组统计写法 2 . CASE WHEN SUM()这个说法可能是个笔误，或者你遇到了某种特殊数据库的扩展语法 3 . 如果真要嵌套统计，应该写成CASE WHEN COUNT() ... END，但这样写性能和可读性都会下降
我之前在2 02 2 年处理一个ERP系统报表需求时，坚持用SUM(CASE WHEN ... END)，最后SQL跑起来比用动态SQL快3 倍。
所以个人强烈推荐这种写法。
你确定看到过CASE WHEN SUM()的例子吗？能发个截图看看吗？