sql 查询 distinc用法

distinct 和group by都需要排序,一样的结果集从执行计划的成本代价来看差距不大,但group by 还涉及到统计,所以应该需要准备工作。所以单纯从等价结果来说,选择distinct比较效率一些。

其实二者没有什么可比性,但是对于不包含聚集函数的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的性能差异原因。

sql 单个字段去重查询 distinc 和 group by的效率问题的更多相关文章

  1. oracle 多字段去重查询

      oracle 多字段去重查询 CreationTime--2018年6月29日15点11分 Author:Marydon 1.情景展示 需要对表BASE_MRI_DEVICE的COMPNAME.F ...

  2. Oracle对字段去重查询所有字段数据

    单个字段: select distinct(a) from tableA; 多个字段,利用max()去重  SELECT  * FROM  GM_PPU_RESIDENT_NORBASE g  WHE ...

  3. 记一次SQL xml字段关联查询

    需求: 一张表是APP表,结构如下: app_category为该游戏所属的类别ID,xml字段类型 另一张表是类别表,就ID对应名称,这就不上图了. 还有一张表是每个游戏的下载记录,结构如下: Do ...

  4. MySQL数据库时间字段按年月日显示并多字段去重查询

    应用服务长久运行,难免要导出一些统计报表. 现在有一个日志表,记录了各种日志,需要导出十月份的登录日志,要求时间按日期显示,且每天用户登陆要去重. 先看日志表的字段构成: logType等于2的是登陆 ...

  5. sql 同一个字段在查询结果中出现两次

    SELECT GET .daytime,    GET.data AS GET,    xh.data AS xh FROM    ( SELECT daytime, SUM ( get_sum ) ...

  6. SQL 多字段去重

    select articleID from (select aeUID, max(articleID) articleID from [article] group by aeUID) a conca ...

  7. SQL去重之distinct和group by的应用

    遇到一个需求,要去重查出某张表的字段一和字段二,但是查出来的结果要按照表中记录的创建时间排序. 于是,第一时间就想到了使用distinct这个去重专用语法了: select distinct col1 ...

  8. Oracle 去重查询

      Oracle 去重查询 CreateTime--2018年2月28日15:38:45 Author:Marydon (一)使用distinct --查询指定区间内表停诊字段的值 SELECT DI ...

  9. mongodb多字段去重

    单字段去重 db.student.distinct("name"); 多字段去重 db.student.aggregate([{      $group:{            ...

随机推荐

  1. Jquery元素选取、常用方法

    一:常用的选择器:(李昌辉) 基本选择器 $("#myDiv") //匹配唯一的具有此id值的元素 $("div") //匹配指定名称的所有元素 $(" ...

  2. jQuery fsBanner 手风琴

    fsbanner是一款自定义功能丰富的响应式网站Banner手风琴特效jQuery插件.该手风琴特效兼容性很好,支持点击和鼠标滑过等触发事件,并且可添加标题或描述. 在线实例 默认 带标题 鼠标滑过 ...

  3. Android MVP 设计模式

    1.基本概念 Model    : 模型   负责处理数据的加载或者存储,比如从网络或本地数据库获取数据等: View     : 视图    负责界面数据的展示,与用户进行交互: Presenter ...

  4. 【译】Spring 4 基于TaskScheduler实现定时任务(注解)

    前言 译文链接:http://websystique.com/spring/spring-job-scheduling-with-scheduled-enablescheduling-annotati ...

  5. Ctrl-A全选这点事(C#,WinForm)

    所有的文本框,不管单行多行都Ctrl-A全选就好了吧?是啊,很方便.Windows的软件基本都是这样.可为什么我们自己制作的WinForm就默认不是这样呢?谁知道呢,可能是WinForm饱受诟病,要改 ...

  6. 最新win7系统64位和32位系统Ghost装机稳定版下载

    系统来自转载:系统妈 一.主要更新:========================== * 更新了系统补丁和Office2007 SP2所有补丁 通过微软漏洞扫描* 更新QQ至7.1  官方正式版* ...

  7. C# 闭包问题-你被”坑“过吗?

    引言 闭包是什么?以前看面试题的时候才发现这个名词. 闭包在实际项目中会有什么问题?现在就让我们一起来看下这个不太熟悉的名词. 如果在实际工作中用到了匿名函数和lamada表达式,那你就应该高度注意啦 ...

  8. bug描述技巧

    进入测试行业已经两年了,我从未认真的考虑过提交一个bug需要注意哪些问题,只是主观的认为我只需要描述清楚就OK了,但是我在工作中发现有个别的开发经常跑来告诉我"这个bug你是不是描述错了&q ...

  9. kubernetes部署Fluentd+Elasticsearch+kibana 日志收集系统

    一.介绍 1. Fluentd 是一个开源收集事件和日志系统,用与各node节点日志数据的收集.处理等等.详细介绍移步-->官方地址:http://fluentd.org/ 2. Elastic ...

  10. LLDB基础知识

    LLDB基础知识 LLDB控制台 Xcode中内嵌了LLDB控制台,在Xcode中代码的下方,我们可以看到LLDB控制台. LLDB控制台平时会输出一些log信息.如果我们想输入命令调试,必须让程序进 ...