SQL Server里Grouping Sets的威力

在SQL Server里,你有没有想进行跨越多个列/纬度的聚集操作,不使用SSAS许可(SQL Server分析服务)。我不是说在生产里使用开发版,也不是说安装盗版SQL Server。

不可能的任务?未必,因为通过SQL Server里所谓的Grouping Sets就可以。在这篇文章里我会给你概括介绍下Grouping Sets,使用它们可以实现哪类查询,什么是它们的性能优势。

使用Grouping Sets的聚合

假设你有个订单表,你想进行跨多个分组的T-SQL聚集查询。在AdventureWorks2012数据库的Sales.SalesOrderHeader表的环境里,这些分组可以类似如下:

  • 在每列分组
  • GROUP BY SalesPersonID, YEAR(OrderDate)
  • GROUP BY CustomerID, YEAR(OrderDate)
  • GROUP BY CustomerID, SalesPersonID, YEAR(OrderDate)

当你想用传统T-SQL查询进行这些各自分组时,你需要多个语句,对各个记录集进行UNION ALL。我们来看这样的查询:

 1 SELECT * FROM
 2 (
 3     -- 1st Grouping Set
 4     SELECT
 5         NULL AS ‘CustomerID‘,
 6         NULL AS ‘SalesPersonID‘,
 7         NULL AS ‘OrderYear‘,
 8         SUM(TotalDue) AS ‘TotalDue‘
 9     FROM Sales.SalesOrderHeader
10     WHERE SalesPersonID IS NOT NULL
11
12     UNION ALL
13
14     -- 2nd Grouping Set
15     SELECT
16         NULL AS ‘CustomerID‘,
17         SalesPersonID,
18         YEAR(OrderDate) AS ‘OrderYear‘,
19         SUM(TotalDue) AS ‘TotalDue‘
20     FROM Sales.SalesOrderHeader
21     WHERE SalesPersonID IS NOT NULL
22     GROUP BY SalesPersonID, YEAR(OrderDate)
23
24     UNION ALL
25
26     -- 3rd Grouping Set
27     SELECT
28         CustomerID,
29         NULL AS ‘SalesPersonID‘,
30         YEAR(OrderDate) AS ‘OrderYear‘,
31         SUM(TotalDue) AS ‘TotalDue‘
32     FROM Sales.SalesOrderHeader
33     WHERE SalesPersonID IS NOT NULL
34     GROUP BY CustomerID, YEAR(OrderDate)
35
36     UNION ALL
37
38     -- 4th Grouping Set
39     SELECT
40         CustomerID,
41         SalesPersonID,
42         YEAR(OrderDate) AS ‘OrderYear‘,
43         SUM(TotalDue) AS ‘TotalDue‘
44     FROM Sales.SalesOrderHeader
45     WHERE SalesPersonID IS NOT NULL
46     GROUP BY CustomerID, SalesPersonID, YEAR(OrderDate)
47 ) AS t
48 ORDER BY CustomerID, SalesPersonID, OrderYear
49 GO

用这个T-SQL语句方法有多个缺点:

  • T-SQL语句本身很庞大,因为每个单独分组都是一个不同查询。
  • 每查询1次,Sales.SalesOrderHeader表需要访问4次。
  • 每查询1次,你在执行计划里会看到SQL Server进行了4次的索引查找(非聚集)(Index Seek (NonClustered) )

如果你使用自SQL Server 2008以后引入的grouping sets功能,就可以大大简化你需要的T-SQL代码。下面代码展示你同样的查询,但这次用grouping sets实现。

 1 SELECT
 2     CustomerID,
 3     SalesPersonID,
 4     YEAR(OrderDate) AS ‘OrderYear‘,
 5     SUM(TotalDue) AS ‘TotalDue‘
 6 FROM Sales.SalesOrderHeader
 7 WHERE SalesPersonID IS NOT NULL
 8 GROUP BY GROUPING SETS
 9 (
10     -- Our 4 different grouping sets
11     (CustomerID, SalesPersonID, YEAR(OrderDate)),
12     (CustomerID, YEAR(OrderDate)),
13     (SalesPersonID, YEAR(OrderDate)),
14     ()
15 )
16 GO

从代码本身可以看到,你只在GROUP BY GROUPING SETS子句里指定需要的分组集——其它的一切都由SQL Server搞定。指定的空括号是所谓的Empty Grouping Set,是跨整个表的聚集。当你看STATISTICS IO输出时,你会发现Sales.SalesOrderHeader只被访问了1次!这是和刚才手工实现的巨大区别。

在执行计划里,SQL Server使用了Table Spool运算符,它把获得的数据临时存储在TempDb里。来自临时表里创建的Worktable的数据在执行计划的第2个分支被使用。因此对来自表的每个分组数据没有重新扫描,这就给整个执行计划的带来了更好的性能。

我们再来看下执行计划,你会发现查询计划包含了3个Stream Aggregate运算符(红色,蓝色,绿色高亮显示)。这3个运算符计算各个分组集:

  • 蓝色高亮的运算符计算CustomerID, SalesPersonID, YEAR(OrderDate的分组集。
  • 红色高亮的运算符计算SalesPersonID, YEAR(OrderDate)的分组集。另外也计算每1列的分组集。
  • 绿色高亮的运算符计算CustomerID, YEAR(OrderDate)的分组集。

2个连续的Stream Aggregate运算符的背后想法是计算所谓的Super Aggregates——聚集的聚集。

小结

在今天的文章里我给你介绍了grouping sets,在SQL Server 2008后引入的增强T-SQL。如你所见grouping sets有2个大优点:简化你的代码,只访问一次数据提高查询性能。

我希望现在你已经能够很好理解grouping sets,如果你能在你的数据库里使用这个功能可以在此留言,非常感谢!

感谢关注!

时间: 2024-10-24 19:13:27

SQL Server里Grouping Sets的威力的相关文章

SQL Server里PIVOT运算符的”红颜祸水“

在今天的文章里我想讨论下SQL Server里一个特别的T-SQL语言结构——自SQL Server 2005引入的PIVOT运算符.我经常引用这个与语言结构是SQL Server里最危险的一个——很快你就会知道为什么.在我们进入特定问题和陷阱前,首先我想给你下使用SQL Server里的PIVOT能实现什么的一个基本概述. 概述 SQL Server里PIVOT运算符背后的基本思想是在T-SQL查询期间,你可以旋转行为列.运算符本身是SQL Server 2005后引入的,主要用在基于建立在实

SQL Server里因丢失索引造成的死锁

原文:SQL Server里因丢失索引造成的死锁 在今天的文章里我想演示下SQL Server里在表上丢失索引如何引起死锁(deadlock)的.为了准备测试场景,下列代码会创建2个表,然后2个表都插入4条记录. 1 -- Create a table without any indexes 2 CREATE TABLE Table1 3 ( 4 Column1 INT, 5 Column2 INT 6 ) 7 GO 8 9 -- Insert a few record 10 INSERT IN

SQL Server里如何随机记录集

今天的文章,我想给你简单介绍下SQL Server里如何随机记录集. 1 SELECT * FROM Person.Person 2 ORDER BY NEWID() 3 GO 这会引入新的UNIQUEIDENTIFIER数据类型列,SQL Server会在那列上进行物理排序操作. 但是在记录集里列本身没有返回,因为ORDER BY子句在查询SELECT部分逻辑后发生,因此也不会改变记录集. 在SQL Server里,简单但很强大的方法用来随机化你的记录集. 感谢关注!

汇总SQL Server里的相关运算符、子句、谓词等

汇总SQL Server里的相关运算符.子句.谓词等 (后续我会往后追加并不断对现有的进行完善和扩展) ◆ TOP1)TOP一般与ORDER BY结合使用,否则TOP出来的结果集没太大意义,除非您另有它意. 2)TOP返回数可以是变量,但必须用括号括入3)结合WITH TIES谓词选项,如果您返回4行,但最后1行有2条相同的结果,那么您TOP 4,最后1行就只是随意返回1行,保证不了结果集的正确性,如果您指定了WITH TIES, 则返回5行,ORDER BY后将最后2条相同的结果都返回,用法:

SQL Server里等待统计(Wait Statistics)介绍

在今天的文章里我想详细谈下SQL Server里的统计等待(Wait Statistics),还有她们如何帮助你立即为什么你的SQL Server当前很慢.一提到性能调优,对我来说统计等待是SQL Server了最重要的概念. 查询为什么等待 在SQL Server里每次你执行1个查询,查询总需要等待.什么?查询总需要等待?是的,你没有看错:但给你执行1个查询时,查询总需要等待.为什么查询需要等待的原因是SQL Server通过所谓的等待统计(Wait Statistics)来跟踪的.在我进入等

SQL Server里的INTERSECT

在今天的文章里,我想讨论下SQL Server里的INTERSECT设置操作.INTERSECT设置操作彼此交叉2个记录集,返回2个集里列值一样的记录.下图演示了这个概念. INTERSECT与INNER JOIN 你会发现,它和2个表间的INNER JOIN几乎一样.但今天我会介绍它们之间的一些重要区别.让我们从创建作为输入的2个简单表开始. 1 -- Create the 1st table 2 CREATE TABLE t1 3 ( 4 Col1 INT, 5 Col2 INT, 6 Co

SQL Server里的自旋锁介绍

在上一篇文章里我讨论了SQL Server里的闩锁.在文章的最后我给你简单介绍了下自旋锁(Spinlock).基于那个基础,今天我会继续讨论SQL Server中的自旋锁,还有给你展示下如何对它们进行故障排除. 为什么我们需要自旋锁? 在上篇文章我已经指出,用闩锁同步多个线程间数据结构访问,在每个共享数据结构前都放置一个闩锁没有意义的.闩锁与此紧密关联:当你不能获得闩锁(因为其他人已经有一个不兼容的闩锁拿到),查询就会强制等待,并进入挂起(SUSPENDED)状态.查询在挂起状态等待直到可以拿到

SQL Server里在文件组间如何移动数据?

平常我不知道被问了几次这样的问题:“SQL  Server里在文件组间如何移动数据?“你意识到这个问题:你只有一个主文件组的默认配置,后来围观了“SQL Server里的文件和文件组”后,你知道,有多个文件的自定义文件组会是个更好的主意.但你现在如何从主文件组里移动现有数据到新加的文件组? 这篇文章的目的是向你展示你如何在文件组间移动数据.首先我会谈下聚集和非聚集索引,然后我会谈下如何在堆表里移动数据.让我们开始吧! 移动聚集和非聚集索引 一般来说在你的表上通常应该有一个聚集索引.有了现存的聚集

SQL Server里ORDER BY的歧义性

在今天的文章里,我想谈下SQL Server里非常有争议和复杂的话题:ORDER BY子句的歧义性. 视图与ORDER BY 我们用一个非常简单的SELECT语句开始. 1 -- A very simple SELECT statement 2 SELECT * FROM Person.Person 3 ORDER BY LastName 4 GO 从刚才列出的代码你可以看到,我们只想从Person.Person表以LastName列排序返回记录.因为我们想能尽可能简单的重用那个SQL语句,最后