探讨SQL compute by的使用分析_MsSql

GROUP BY子句有个缺点,就是返回的结果集中只有合计数据,而没有原始的详细记录。如果想在SQL SERVER中完成这项工作,可以使用COMPUTE BY子句。COMPTE生成合计作为附加的汇总列出现在结果集的最后。当与BY一起使用时,COMPUTE 子句在结果集内生成控制中断和分类汇总。

下列 SELECT 语句使用简单 COMPUTE 子句生成 titles 表中 price 及 advance 的求和总计:

复制代码 代码如下:

USE pubs
SELECT type, price, advance
FROM titles
ORDER BY type
COMPUTE SUM(price), SUM(advance)

下列查询在 COMPUTE 子句中加入可选的 BY 关键字,以生成每个组的小计:

USE pubs

复制代码 代码如下:

SELECT type, price, advance
FROM titles
ORDER BY type
COMPUTE SUM(price), SUM(advance) BY type

此 SELECT 语句的结果用12 个结果集返回,六个组中的每个组都有两个结果集。每个组的第一个结果集是一个行集,其中包含选择列表中所请求的信息。每个组的第二个结果集包含 COMPUTE 子句中两个 SUM 函数的小计。

compute by 子句的规则:

(1)不能将distinct与行统计函数一起使用

(2)compute ??? by 子句中 ???出的列必须出现在选择列表中

(3)不能在含有compute by 子句的语句中使用select into 子句,因为包括compute 子句的语句会产生不规则的行。

(4)如果使用了compute by子句,则必须使用order by 子句, 而且compute by子句中的列必须包含在order by 子句中,并且对列的前后顺序和起始项都要一致(说白了compute by子句中的列必须是order by子句中列表的全部,或者前边的连续几个)。

(5)如果compute 省略了 by ,则order by 也可以省略

(6)如果compute by 子句包含多列时,会将一个组(第一个列分的组)分成若干个子组(利用后面的列),并对每层子组进行统计。

(7)使用多个compute by子句时,会分别按不同的组统计出结果。详细信息还是按照正常的第一个分组方式显示。

(8)compute by 子句中可以使用多个统计函数,他们互不影响

(9)compute by 子句中可以不包含by ,而只用compute  此时不对前面信息分组,而只对全部信息进行统计。

比较 COMPUTE 和 GROUP BY
COMPUTE 和 GROUP BY 之间的区别汇总如下:
GROUP BY 生成单个结果集。每个组都有一个只包含分组依据列和显示该组子聚合的聚合函数的行。选择列表只能包含分组依据列和聚合函数。

COMPUTE 生成多个结果集。一类结果集包含每个组的明细行,其中包含选择列表中的表达式。另一类结果集包含组的子聚合,或 SELECT 语句
的总聚合。选择列表可包含除分组依据列或聚合函数之外的其它表达式。聚合函数在 COMPUTE 子句中指定,而不是在选择列表中。
下列查询使用 GROUP BY 和聚合函数;该查询将返回一个结果集,其中每个组有一行,该行中包含该组的聚合小计:
USE pubs
SELECT type, SUM(price), SUM(advance)
FROM titles
GROUP BY type

说明 在 COMPUTE 或 COMPUTE BY 子句中,不能包含 ntext、text 或 image 数据类型。

时间: 2024-09-23 11:00:27

探讨SQL compute by的使用分析_MsSql的相关文章

探讨SQL compute by的使用分析

GROUP BY子句有个缺点,就是返回的结果集中只有合计数据,而没有原始的详细记录.如果想在SQL SERVER中完成这项工作,可以使用COMPUTE BY子句.COMPTE生成合计作为附加的汇总列出现在结果集的最后.当与BY一起使用时,COMPUTE 子句在结果集内生成控制中断和分类汇总. 下列 SELECT 语句使用简单 COMPUTE 子句生成 titles 表中 price 及 advance 的求和总计:复制代码 代码如下:USE pubsSELECT type, price, adv

sql 查询慢的原因分析_MsSql

查询速度慢的原因很多,常见如下几种: 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2.I/O吞吐量小,形成了瓶颈效应. 3.没有创建计算列导致查询不优化. 4.内存不足 5.网络速度慢 6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8.sp_lock,sp_who,活动的用户查看,原因是读写竞争资源. 9.返回了不必要的行和列 10.查询语句不好,没有优化 ●可以通过如下方法来优化查询

SQL语句的执行原理分析_MsSql

原理:第一步:应用程序把查询SQL语句发给服务器端执行.我们在数据层执行SQL语句时,应用程序会连接到相应的数据库服务器,把SQL语句发送给服务器处理.第二步:服务器解析请求的SQL语句.1:SQL计划缓存,经常用查询分析器的朋友大概都知道这样一个事实,往往一个查询语句在第一次运行的时候需要执行特别长的时间,但是如果你马上或者在一定时间内运行同样的语句,会在很短的时间内返回查询结果. 原因:1):服务器在接收到查询请求后,并不会马上去数据库查询,而是在数据库中的计划缓存中找是否有相对应的执行计划

探讨SQL Server 2005的评价函数

一. 简介 在2005年11月份,微软发行了三种新产品系列:Visual Studio 2005,SQL Server 2005和.NET框架2.0(它包括ASP.NET 2.0).SQL Server 2005是微软自从其上一个主要发行版本SQL Server 2000以来最新版本的数据库平台.在过去五年的发展中,SQL Server中加入了大量的新特征,所有这些新内容都被总结到微软网站的一篇文章<What's New in SQL Server 2005?>中.使用SQL Server 2

SQL Server -&gt;&gt; 深入探讨SQL Server 2016新特性之 --- Temporal Table(历史表)

原文:SQL Server ->> 深入探讨SQL Server 2016新特性之 --- Temporal Table(历史表) 作为SQL Server 2016(CTP3.x)的另一个新特性,Temporal Table(历史表)记录了表历史上任何时间点所有的数据改动.Temporal Table其实早在ANSI SQL 2011就提出了,而SAP HANA, DB2和Oracle早已在它们的产品中加入/实现了这一特性.所以说微软其实是落后了几个竞争对手.既然在CTP3.0中加入了,相信

php防止sql注入漏洞代码和分析

 这篇文章主要介绍了php防止sql注入漏洞代码和分析,最近提供了几种常见攻击的正则表达式,大家参考使用吧 注入漏洞代码和分析 代码如下: <?php  function customError($errno, $errstr, $errfile, $errline)  {      echo "<b>Error number:</b> [$errno],error on line $errline in $errfile<br />";   

工厂设计模式的探讨——iOS类簇的应用分析

工厂设计模式的探讨--iOS类簇的应用分析 一.何为设计模式 什么是设计模式,先来看段度娘的话:       设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的:设计模式使代码编制真正工程化:设计模式是软件工程的基石脉络,如同大厦的结构一样. 其实我们不需要这么专业,在我的理解,设计模式就是一种规范化的编程习惯,养成了这样的

Joomla! v3.7 SQL注入高危漏洞技术分析(CVE-2017-8917)

本文讲的是Joomla! v3.7 SQL注入高危漏洞技术分析(CVE-2017-8917),近日,全球知名内容管理系统Joomla!爆出高危安全漏洞,任何能访问网站的用户都可以发起攻击,窃取用户会话和账号密码. 安全风险:严重 漏洞类型:SQL注入 影响版本:3.7 修复版本:3.7.1 CVE编号:CVE-2017-8917 漏洞描述 com_fields组件出现漏洞,com_fields组件是在3.7版本添加的,如果你使用此版本,将受到影响,并应尽快更新.这个组件可以公开访问,意味着任何能

SQL Server 索引结构及其使用(二) 改善SQL语句第1/3页_MsSql

比如: select * from table1 where name=''zhangsan'' and tID > 10000 和执行: select * from table1 where tID > 10000 and name=''zhangsan'' 一些人不知道以上两条语句的执行效率是否一样,因为如果简单的从语句先后上看,这两个语句的确是不一样,如果tID是一个聚合索引,那么后一句仅仅从表的10000条以后的记录中查找就行了:而前一句则要先从全表中查找看有几个name=''zhan