- 浏览: 123266 次
- 性别:
文章分类
- 全部博客 (86)
- struts2 (1)
- tomcat (5)
- Oracle (12)
- Oracle基础 (10)
- Oracle-IMP (1)
- Oracle-FUNCTION (1)
- java-基础 (21)
- java-术语 (1)
- java-Error (1)
- java-Exception (2)
- java-数据库连接池 (1)
- java-excel-txt (1)
- js-字符串 (1)
- js-基础 (3)
- Python (1)
- Access-基础 (1)
- Often-English (1)
- java-版本控制 (5)
- 报表-IReport (2)
- Mysql (4)
- Java IDE (5)
- Shrio (1)
- SpringMVC (1)
最新评论
有时候进行分组查询的时候 可以用DISTINCT和GROUP BY 、所以难免需要比较一下、
搜了一下 感觉这个比较权威 记一下
http://yangtingkun.itpub.net/post/468/227628
-------------------------------------------------------------------------------------------
其实二者没有什么可比性,但是对于不包含聚集函数的GROUP BY操作来说,和DISTINCT操作是等价的。不过虽然二者的结果是一样的,但是二者的执行计划并不相同。
在Oracle9i中:
SQL> SELECT * FROM V$VERSION;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
SQL> CREATE TABLE T AS SELECT ROWNUM ID, A.* FROM DBA_OBJECTS A;
表已创建。
SQL> CREATE INDEX IND_T_CREATED ON T (CREATED);
索引已创建。
SQL> ALTER TABLE T MODIFY CREATED NOT NULL;
表已更改。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
会话已更改。
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'T')
PL/SQL 过程已成功完成。
SQL> SET AUTOT ON EXP
SQL> SELECT COUNT(*) FROM (SELECT DISTINCT CREATED FROM T);
COUNT(*)
----------
4794
执行计划
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=65 Card=1)
1 0 SORT (AGGREGATE)
2 1 VIEW (Cost=65 Card=4794)
3 2 SORT (UNIQUE) (Cost=65 Card=4794 Bytes=38352)
4 3 INDEX (FAST FULL SCAN) OF 'IND_T_CREATED' (NON-UNIQUE) (Cost=4 Card=41802 Bytes=334416)
SQL> SELECT COUNT(*) FROM (SELECT CREATED FROM T GROUP BY CREATED);
COUNT(*)
----------
4794
执行计划
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=65 Card=1 Bytes=2)
1 0 SORT (AGGREGATE)
2 1 VIEW (Cost=65 Card=4794 Bytes=9588)
3 2 SORT (GROUP BY) (Cost=65 Card=4794 Bytes=38352)
4 3 INDEX (FAST FULL SCAN) OF 'IND_T_CREATED' (NON-UNIQUE) (Cost=4 Card=41802 Bytes=334416)
从执行计划上看,DISTINCT的操作是SORT (UNIQUE),而GROUP BY是SORT (GROUP BY)。DISTINCT操作只需要找出所有不同的值就可以了。而GROUP BY操作还要为其他聚集函数进行准备工作。从这一点上将,GROUP BY操作做的工作应该比DISTINCT所做的工作要多一些。
除了这一点,基本上看不到DISTINCT和GROUP BY(没有聚集函数的情况)有什么区别,而且从执行效率上也看不到明显的差异。
不过从10g开始,二者的差异开始体现出来了。
SQL> CONN YANGTK/YANGTK@YTK已连接。
SQL> SET AUTOT OFF
SQL> SET TIMING OFF
SQL> CREATE TABLE T AS SELECT ROWNUM ID, A.* FROM DBA_OBJECTS A;
表已创建。
SQL> CREATE INDEX IND_T_CREATED ON T (CREATED);
索引已创建。
SQL> ALTER TABLE T MODIFY CREATED NOT NULL;
表已更改。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
会话已更改。
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'T')
PL/SQL 过程已成功完成。
SQL> SET AUTOT ON
SQL> SET TIMING ON
建立好测试环境后,看一看标准分页函数中,两个操作的差异:
SQL> SELECT *
2 FROM
3 (
4 SELECT ROWNUM RN, A.*
5 FROM
6 (
7 SELECT CREATED
8 FROM T
9 GROUP BY CREATED
10 ) A
11 WHERE ROWNUM < 20
12 )
13 WHERE RN >= 10;
RN CREATED
---------- -------------------
10 2005-12-19 17:07:57
11 2005-12-19 17:07:58
12 2005-12-19 17:08:24
13 2005-12-19 17:08:25
14 2005-12-19 17:08:26
15 2005-12-19 17:08:27
16 2005-12-19 17:08:28
17 2005-12-19 17:08:29
18 2005-12-19 17:08:33
19 2005-12-19 17:08:35
已选择10行。
已用时间: 00: 00: 00.06
执行计划
----------------------------------------------------------
Plan hash value: 3639065582
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 19 | 418 | 1 (0)|
|* 1 | VIEW | | 19 | 418 | 1 (0)|
|* 2 | COUNT STOPKEY | | | | |
| 3 | VIEW | | 969 | 8721 | 1 (0)|
|* 4 | SORT GROUP BY STOPKEY| | 969 | 7752 | 1 (0)|
| 5 | INDEX FULL SCAN | IND_T_CREATED | 969 | 7752 | 1 (0)|
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("RN">=10)
2 - filter(ROWNUM<20)
4 - filter(ROWNUM<20)
统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
67 consistent gets
0 physical reads
0 redo size
642 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed
SQL> SELECT *
2 FROM
3 (
4 SELECT ROWNUM RN, A.*
5 FROM
6 (
7 SELECT DISTINCT CREATED
8 FROM T
9 ) A
10 WHERE ROWNUM < 20
11 )
12 WHERE RN >= 10;
RN CREATED
---------- -------------------
10 2005-12-19 17:07:57
11 2005-12-19 17:07:58
12 2005-12-19 17:08:24
13 2005-12-19 17:08:25
14 2005-12-19 17:08:26
15 2005-12-19 17:08:27
16 2005-12-19 17:08:28
17 2005-12-19 17:08:29
18 2005-12-19 17:08:33
19 2005-12-19 17:08:35
已选择10行。
已用时间: 00: 00: 00.03
执行计划
----------------------------------------------------------
Plan hash value: 1650124153
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 19 | 418 | 14 (36)|
|* 1 | VIEW | | 19 | 418 | 14 (36)|
|* 2 | COUNT STOPKEY | | | | |
| 3 | VIEW | | 987 | 8883 | 14 (36)|
|* 4 | SORT GROUP BY STOPKEY| | 987 | 7896 | 14 (36)|
| 5 | INDEX FAST FULL SCAN| IND_T_CREATED | 50333 | 393K| 10 (10)|
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("RN">=10)
2 - filter(ROWNUM<20)
4 - filter(ROWNUM<20)
统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
73 consistent gets
0 physical reads
0 redo size
642 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed
出乎意料的是,GROUP BY操作的COST更低,而且逻辑读也小,这似乎与二者的工作量成反比。仔细观察执行计划发现,问题的根源来自于GROUP BY使用INDEX FULL SCAN,而DISTINCT使用了INDEX FAST FULL SCAN。也许有人会感到奇怪,索引的快速全扫描不是要比索引全扫描效率更高吗?对于读取所有数据的情况下,确实是索引快速全扫效率更高。但是由于这里采用了分页,只取前20条数据,而且Oracle的10g增加了GROUP BY STOPKEY这种新的执行路径,因此在这里GROUP BY操作的效率更高。
观察执行计划中的处理行数可以发现,索引全扫描由于是按照索引的顺序扫描,因此利用了STOPKEY,仅仅处理了969条记录就停了下来。而对于DISTINCT操作的快速索引全速而言,显然没有使用STOPKEY,读取了所有的50333条记录。这就是GROUP BY和DISTINCT的性能差异原因。
-----------------------------------------------------------------------
相对而言 我还是比较支持用GROUP BY
搜了一下 感觉这个比较权威 记一下
http://yangtingkun.itpub.net/post/468/227628
-------------------------------------------------------------------------------------------
其实二者没有什么可比性,但是对于不包含聚集函数的GROUP BY操作来说,和DISTINCT操作是等价的。不过虽然二者的结果是一样的,但是二者的执行计划并不相同。
在Oracle9i中:
SQL> SELECT * FROM V$VERSION;
BANNER
----------------------------------------------------------------
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production
SQL> CREATE TABLE T AS SELECT ROWNUM ID, A.* FROM DBA_OBJECTS A;
表已创建。
SQL> CREATE INDEX IND_T_CREATED ON T (CREATED);
索引已创建。
SQL> ALTER TABLE T MODIFY CREATED NOT NULL;
表已更改。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
会话已更改。
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'T')
PL/SQL 过程已成功完成。
SQL> SET AUTOT ON EXP
SQL> SELECT COUNT(*) FROM (SELECT DISTINCT CREATED FROM T);
COUNT(*)
----------
4794
执行计划
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=65 Card=1)
1 0 SORT (AGGREGATE)
2 1 VIEW (Cost=65 Card=4794)
3 2 SORT (UNIQUE) (Cost=65 Card=4794 Bytes=38352)
4 3 INDEX (FAST FULL SCAN) OF 'IND_T_CREATED' (NON-UNIQUE) (Cost=4 Card=41802 Bytes=334416)
SQL> SELECT COUNT(*) FROM (SELECT CREATED FROM T GROUP BY CREATED);
COUNT(*)
----------
4794
执行计划
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=65 Card=1 Bytes=2)
1 0 SORT (AGGREGATE)
2 1 VIEW (Cost=65 Card=4794 Bytes=9588)
3 2 SORT (GROUP BY) (Cost=65 Card=4794 Bytes=38352)
4 3 INDEX (FAST FULL SCAN) OF 'IND_T_CREATED' (NON-UNIQUE) (Cost=4 Card=41802 Bytes=334416)
从执行计划上看,DISTINCT的操作是SORT (UNIQUE),而GROUP BY是SORT (GROUP BY)。DISTINCT操作只需要找出所有不同的值就可以了。而GROUP BY操作还要为其他聚集函数进行准备工作。从这一点上将,GROUP BY操作做的工作应该比DISTINCT所做的工作要多一些。
除了这一点,基本上看不到DISTINCT和GROUP BY(没有聚集函数的情况)有什么区别,而且从执行效率上也看不到明显的差异。
不过从10g开始,二者的差异开始体现出来了。
SQL> CONN YANGTK/YANGTK@YTK已连接。
SQL> SET AUTOT OFF
SQL> SET TIMING OFF
SQL> CREATE TABLE T AS SELECT ROWNUM ID, A.* FROM DBA_OBJECTS A;
表已创建。
SQL> CREATE INDEX IND_T_CREATED ON T (CREATED);
索引已创建。
SQL> ALTER TABLE T MODIFY CREATED NOT NULL;
表已更改。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';
会话已更改。
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, 'T')
PL/SQL 过程已成功完成。
SQL> SET AUTOT ON
SQL> SET TIMING ON
建立好测试环境后,看一看标准分页函数中,两个操作的差异:
SQL> SELECT *
2 FROM
3 (
4 SELECT ROWNUM RN, A.*
5 FROM
6 (
7 SELECT CREATED
8 FROM T
9 GROUP BY CREATED
10 ) A
11 WHERE ROWNUM < 20
12 )
13 WHERE RN >= 10;
RN CREATED
---------- -------------------
10 2005-12-19 17:07:57
11 2005-12-19 17:07:58
12 2005-12-19 17:08:24
13 2005-12-19 17:08:25
14 2005-12-19 17:08:26
15 2005-12-19 17:08:27
16 2005-12-19 17:08:28
17 2005-12-19 17:08:29
18 2005-12-19 17:08:33
19 2005-12-19 17:08:35
已选择10行。
已用时间: 00: 00: 00.06
执行计划
----------------------------------------------------------
Plan hash value: 3639065582
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 19 | 418 | 1 (0)|
|* 1 | VIEW | | 19 | 418 | 1 (0)|
|* 2 | COUNT STOPKEY | | | | |
| 3 | VIEW | | 969 | 8721 | 1 (0)|
|* 4 | SORT GROUP BY STOPKEY| | 969 | 7752 | 1 (0)|
| 5 | INDEX FULL SCAN | IND_T_CREATED | 969 | 7752 | 1 (0)|
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("RN">=10)
2 - filter(ROWNUM<20)
4 - filter(ROWNUM<20)
统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
67 consistent gets
0 physical reads
0 redo size
642 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed
SQL> SELECT *
2 FROM
3 (
4 SELECT ROWNUM RN, A.*
5 FROM
6 (
7 SELECT DISTINCT CREATED
8 FROM T
9 ) A
10 WHERE ROWNUM < 20
11 )
12 WHERE RN >= 10;
RN CREATED
---------- -------------------
10 2005-12-19 17:07:57
11 2005-12-19 17:07:58
12 2005-12-19 17:08:24
13 2005-12-19 17:08:25
14 2005-12-19 17:08:26
15 2005-12-19 17:08:27
16 2005-12-19 17:08:28
17 2005-12-19 17:08:29
18 2005-12-19 17:08:33
19 2005-12-19 17:08:35
已选择10行。
已用时间: 00: 00: 00.03
执行计划
----------------------------------------------------------
Plan hash value: 1650124153
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)|
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 19 | 418 | 14 (36)|
|* 1 | VIEW | | 19 | 418 | 14 (36)|
|* 2 | COUNT STOPKEY | | | | |
| 3 | VIEW | | 987 | 8883 | 14 (36)|
|* 4 | SORT GROUP BY STOPKEY| | 987 | 7896 | 14 (36)|
| 5 | INDEX FAST FULL SCAN| IND_T_CREATED | 50333 | 393K| 10 (10)|
-------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("RN">=10)
2 - filter(ROWNUM<20)
4 - filter(ROWNUM<20)
统计信息
----------------------------------------------------------
1 recursive calls
0 db block gets
73 consistent gets
0 physical reads
0 redo size
642 bytes sent via SQL*Net to client
385 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
10 rows processed
出乎意料的是,GROUP BY操作的COST更低,而且逻辑读也小,这似乎与二者的工作量成反比。仔细观察执行计划发现,问题的根源来自于GROUP BY使用INDEX FULL SCAN,而DISTINCT使用了INDEX FAST FULL SCAN。也许有人会感到奇怪,索引的快速全扫描不是要比索引全扫描效率更高吗?对于读取所有数据的情况下,确实是索引快速全扫效率更高。但是由于这里采用了分页,只取前20条数据,而且Oracle的10g增加了GROUP BY STOPKEY这种新的执行路径,因此在这里GROUP BY操作的效率更高。
观察执行计划中的处理行数可以发现,索引全扫描由于是按照索引的顺序扫描,因此利用了STOPKEY,仅仅处理了969条记录就停了下来。而对于DISTINCT操作的快速索引全速而言,显然没有使用STOPKEY,读取了所有的50333条记录。这就是GROUP BY和DISTINCT的性能差异原因。
-----------------------------------------------------------------------
相对而言 我还是比较支持用GROUP BY
发表评论
-
ora12541-TNS : 没有监听器
2013-11-04 10:42 775以前也遇到过类似问题,觉得没多大点事,无非地址了,主机名错 ... -
ORA-01110 表空间 临时表空间
2013-10-28 15:13 739sqlplus /as sysdba; shutdown ... -
count() over() and sum() over() group by
2012-07-09 14:27 1766eg: select t.name,count(*) coun ... -
[转]把字母数字串转换为数值
2012-06-28 16:48 1213http://www.blogjava.net/jxhkwhy ... -
在sqlplus中修改open_cursors
2012-04-26 18:01 3005http://www.zhuoda.org/air_tuyh/ ... -
spfileorcl.ora改错、或者删除补救办法
2012-04-26 17:32 1045create spfile='D:\oracle\produc ... -
replace函数
2012-02-10 15:32 1067replace(字段,'包含的字符串','替换成的字符串') ... -
wm_concat(column)函数
2012-02-10 15:19 1039很早之前接触过这个函数、为防止再次遗忘记录: 这个函数的主要功 ... -
oracle导入导出命令
2012-02-08 14:38 660原文:http://hi.baidu.com/2008_ok/ ... -
oracle 创建 修改 删除 用户(待整理)
2012-02-08 12:50 815创建: create user testuser identi ... -
批量添加、修改 (未完待续)
2012-02-06 12:02 812批量添加: insert into A(a,b,c) sele ...
相关推荐
在MySQL数据库中,`DISTINCT` 和 `GROUP BY` 是两个非常重要的SQL关键字,它们都可以用来处理数据的去重问题,但在实际应用中,两者的使用场景和效果有所差异。 首先,`DISTINCT` 关键字的主要作用是去除查询结果中...
用C#实现对DataTable的JOIN,GROUP BY,FILTER,UNIONALL,DISTINCT
在MySQL数据库中,`DISTINCT` 和 `GROUP BY` 是两种用于数据去重和分组统计的SQL语句,它们虽然都可以帮助我们处理重复数据,但有着不同的应用场景和执行机制。 1. `DISTINCT` 关键字: - `DISTINCT` 主要用于去除...
在MySQL数据库中,`DISTINCT` 和 `GROUP BY` 是两个用于数据去重的语句,但它们在功能和性能上有显著的区别。这次的测试主要比较了这两种方法在不同条件下的执行效率,尤其是在数据量较大的情况下。 首先,`...
首先,理解`DISTINCT`与`GROUP BY`的区别。`DISTINCT`用于返回不重复的行,而`GROUP BY`则用于对数据进行分组并计算每个组的聚合函数(如COUNT、SUM、AVG等)。在某些情况下,`GROUP BY`可以提供与`DISTINCT`类似的...
在MySQL数据库中,`DISTINCT`和`GROUP BY`是两个非常重要的查询语句,它们在处理数据去重和分组方面发挥着关键作用。本文将详细介绍这两个语句的使用方法。 首先,`DISTINCT`关键字是用来去除查询结果中重复记录的...
在内部,`DISTINCT`的实现与`GROUP BY`相似,但在处理结果集时有一些关键区别。 当MySQL执行`DISTINCT`查询时,它首先会对数据进行分组,就像`GROUP BY`一样,但每个分组只选择一条记录返回。在某些情况下,如果...
然而,当`DISTINCT`和`GROUP BY`结合使用时,它们可以实现更复杂的数据筛选。 例如,考虑你给出的表格`table1`,包含以下字段:`id`, `RegName`, `PositionSN`, `PersonSN`。如果你想要获取不重复的`RegName`, `...
2. **使用DISTINCT**: 当需要去除重复值时,可以在聚合函数中使用`DISTINCT`,如`SELECT CategoryID, AVG(DISTINCT UnitPrice), COUNT(DISTINCT UnitPrice) FROM Products WHERE UnitPrice > 30 GROUP BY CategoryID...
`DISTINCT`通常与`GROUP BY`和聚合函数(如`COUNT`, `SUM`, `AVG`, `MIN`, `MAX`)一起使用,用于计算每个分组的唯一值。例如,计算每个部门的员工数量: ```sql SELECT DISTINCT department, COUNT(*) AS employee...
MySQL通常使用GROUPBY(本质上是排序动作)完成DISTINCT操作,如果DISTINCT操作和ORDERBY操作组合使用,通常会用到临时表.这样会影响性能. 在一些情况下,MySQL可以使用索引优化DISTINCT操作,但需要活学活用.本文涉及一个...
2. **合理使用索引**:确保`GROUP BY`和`ORDER BY`中涉及的字段有适当的索引支持。 3. **限制返回行数**:使用`LIMIT`限制返回的结果行数,特别是与`DISTINCT`结合使用时。 4. **理解查询执行计划**:使用`EXPLAIN`...
在数据库查询语言SQL中,`GROUP BY`语句是一种非常强大的工具,它能够帮助我们对数据进行分组处理,以便更好地进行数据分析和汇总。下面将详细介绍`GROUP BY`的基本语法、常用场景以及如何与其他SQL语句如聚合函数、...
由于没有提供具体的博客内容,以上分析是基于常见的SQL查询优化技术和`GROUP BY`的替代写法进行的推测。在实际阅读博客或文档(如`大数据量分组.doc`)时,应能获取更详细的信息和具体案例。通过深入学习这些内容,...