前几天我学了一些关于SQL的简单知识:
SELECT c FROM myTbl GROUP BY C
结果与:
SELECT DISTINCT C FROM myTbl
我好奇的是,SQL引擎处理命令的方式有什么不同,还是它们真的是一样的东西?
我个人更喜欢独特的语法,但我相信这更多是出于习惯而不是其他原因。
编辑:这不是一个关于聚合的问题。理解了GROUP BY与聚合函数的使用。
前几天我学了一些关于SQL的简单知识:
SELECT c FROM myTbl GROUP BY C
结果与:
SELECT DISTINCT C FROM myTbl
我好奇的是,SQL引擎处理命令的方式有什么不同,还是它们真的是一样的东西?
我个人更喜欢独特的语法,但我相信这更多是出于习惯而不是其他原因。
编辑:这不是一个关于聚合的问题。理解了GROUP BY与聚合函数的使用。
当前回答
从“SQL语言”的角度来看,这两种结构是等价的,你选择哪一种是我们都必须做出的“生活方式”选择之一。我认为DISTINCT更明确(因此对继承你代码的人更体贴)是一个很好的例子,但这并不意味着GROUP BY结构是一个无效的选择。
我认为“GROUP BY是用于聚合的”是错误的重点。人们应该意识到set函数(MAX, MIN, COUNT等)可以省略,这样他们就可以理解编码器的意图。
理想的优化器将识别等效的SQL结构,并始终相应地选择理想的计划。对于现实生活中选择的SQL引擎,您必须测试:)
PS注意DISTINCT关键字在select子句中的位置可能会产生不同的结果,例如对比:
SELECT COUNT(DISTINCT C) FROM myTbl;
SELECT DISTINCT COUNT(C) FROM myTbl;
其他回答
MusiGenesis的回答在功能上是正确的,关于你的问题;SQL Server足够聪明,可以意识到如果你使用“Group By”而不使用任何聚合函数,那么你实际上的意思是“Distinct”——因此它会生成一个执行计划,就像你只是使用“Distinct”一样。
然而,我认为重要的是要注意Hank的回应-漫不经心的对待“Group By”和“Distinct”可能会导致一些有害的陷阱,如果你不小心的话。说这“不是一个关于聚合的问题”并不完全正确,因为您问的是两个SQL查询关键字之间的功能差异,其中一个是用于聚合的,而另一个不是。
锤子有时可以用来拧螺丝,但如果你手边有螺丝刀,那又何苦呢?
(为了便于类比,Hammer:螺丝刀::GroupBy: Distinct和screw =>获取表列中唯一值的列表)
在这个特定的查询中没有区别。但是,当然,如果您添加任何聚合列,那么就必须使用group by。
我阅读了上面所有的评论,但除了聚合位之外,没有看到任何人指出Group By和Distinct之间的主要区别。
Distinct返回所有行,然后重复删除它们,而Group By则在算法逐条读取时重复删除行。
这意味着它们可以产生不同的结果!
例如,下面的代码会产生不同的结果:
SELECT distinct ROW_NUMBER() OVER (ORDER BY Name), Name FROM NamesTable
SELECT ROW_NUMBER() OVER (ORDER BY Name), Name FROM NamesTable
GROUP BY Name
如果表中有10个名字,其中一个是另一个的副本,那么第一个查询返回10行,而第二个查询返回9行。
原因就是我上面说的,这样他们就能表现得不一样!
除了聚合函数的使用外,group by子句和distinct子句之间没有显著区别。 两者都可以用来区分值,但如果在性能的角度组由更好。 在使用distinct关键字时,内部采用排序操作,可在执行计划中查看。
试试简单的例子
Declare @tmpresult table
(
Id tinyint
)
Insert into @tmpresult
Select 5
Union all
Select 2
Union all
Select 3
Union all
Select 4
Select distinct
Id
From @tmpresult
仅仅从重复删除功能的角度来看有什么不同
除了与DISTINCT不同的事实,GROUP BY允许每个组聚合数据(这已经被许多其他答案提到),在我看来最重要的区别是,这两个操作“发生”在SELECT语句中执行的操作的逻辑顺序中的两个非常不同的步骤。
以下是最重要的操作:
FROM(包括JOIN、APPLY等) 在哪里 GROUP BY(可以删除重复项) 聚合 有 窗口函数 选择 DISTINCT(可以删除重复项) UNION, INTERSECT, EXCEPT(可删除重复项) 命令 抵消 限制
如您所见,每个操作的逻辑顺序影响着可以用它做什么以及它如何影响后续操作。特别地,GROUP BY操作“发生在”SELECT操作(投影)之前的事实意味着:
它不依赖于投影(这可能是一个优势) 它不能使用来自投影的任何值(这可能是一个缺点)
1. 它不依赖于投影
一个不依赖于投影的例子是,如果你想计算不同值的窗口函数:
SELECT rating, row_number() OVER (ORDER BY rating) AS rn
FROM film
GROUP BY rating
当对Sakila数据库运行时,会产生:
rating rn
-----------
G 1
NC-17 2
PG 3
PG-13 4
R 5
DISTINCT很难做到这一点:
SELECT DISTINCT rating, row_number() OVER (ORDER BY rating) AS rn
FROM film
这个查询是“错误的”,结果如下:
rating rn
------------
G 1
G 2
G 3
...
G 178
NC-17 179
NC-17 180
...
这不是我们想要的。DISTINCT操作“发生在”投影之后,因此我们不能再删除DISTINCT评级,因为窗口函数已经计算和投影了。为了使用DISTINCT,我们必须嵌套查询的这一部分:
SELECT rating, row_number() OVER (ORDER BY rating) AS rn
FROM (
SELECT DISTINCT rating FROM film
) f
旁注:在这种特殊情况下,我们还可以使用DENSE_RANK()
SELECT DISTINCT rating, dense_rank() OVER (ORDER BY rating) AS rn
FROM film
2. 它不能使用来自投影的任何值
SQL的缺点之一是有时冗长。出于与我们之前看到的相同的原因(即操作的逻辑顺序),我们不能“轻松地”根据我们所投射的东西进行分组。
这是无效的SQL:
SELECT first_name || ' ' || last_name AS name
FROM customer
GROUP BY name
这是有效的(重复表达式)
SELECT first_name || ' ' || last_name AS name
FROM customer
GROUP BY first_name || ' ' || last_name
这也是有效的(嵌套表达式)
SELECT name
FROM (
SELECT first_name || ' ' || last_name AS name
FROM customer
) c
GROUP BY name
我曾在一篇博客文章中更深入地讨论过这个话题