`
bestxiaok
  • 浏览: 459720 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

UNION替换OR效率测试及总结

阅读更多
大家在做SQL优化的过程中,可能都知道一个事实:某些情况下使用UNION替换OR可以提高SQL的运行效率。

您知道这个“某些情况”指的是什么么?

解释一下,“某些情况”指的是:使用的表字段要有索引。

这个实验,给大家展示一下这个结论

1.创建测试表
sec@ora10g> drop table t;

Table dropped.

sec@ora10g> create table t as select * from all_objects;

Table created.

sec@ora10g> alter table t rename column owner to x;

Table altered.

sec@ora10g> alter table t rename column object_name to y;

Table altered.

sec@ora10g> update t set x = 'secooler';

4785 rows updated.

OK,通过上面的初始化,我们得到了这个测试表T,我们关心它的第一个和第二个字段,修改名字后是x字段和y字段
x字段内容统一修改为“secooler”,以便模拟使用这个字段得到大量返回结果
y字段指定特定值后,模拟返回一条记录

2.开启autotrace,跟踪不同的SQL执行(为使执行计划稳定,请多次执行,得到稳定输出结果)
用到的测试SQL语句是以下三条
1)返回记录多的条件放在where子句的前面
select * from t where x = 'secooler' or y = 'T';
2)返回记录多的条件放在where子句的后面
select * from t where y = 'T' or x = 'secooler';
3)使用UNION改写上面的OR语句
select * from t where x = 'secooler'
union
select * from t where y = 'T'
/

3.先看一下,在没有创建索引情况下的实验效果
sec@ora10g> set autotrace traceonly
sec@ora10g> select * from t where x = 'secooler' or y = 'T';

4782 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  4583 |   572K|    16   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  4583 |   572K|    16   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("X"='secooler' OR "Y"='T')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        111  consistent gets
          0  physical reads
          0  redo size
     206142  bytes sent via SQL*Net to client
       1009  bytes received via SQL*Net from client
         49  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4782  rows processed

sec@ora10g> select * from t where y = 'T' or x = 'secooler';

4782 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  4583 |   572K|    16   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  4583 |   572K|    16   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("Y"='T' OR "X"='secooler')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        111  consistent gets
          0  physical reads
          0  redo size
     206142  bytes sent via SQL*Net to client
       1009  bytes received via SQL*Net from client
         49  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4782  rows processed

sec@ora10g> select * from t where x = 'secooler'
union
select * from t where y = 'T'
/
  2    3    4
4782 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2618920678

------------------------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      |  4584 |   573K|       |   168  (12)| 00:00:03 |
|   1 |  SORT UNIQUE        |      |  4584 |   573K|  1448K|   168  (12)| 00:00:03 |
|   2 |   UNION-ALL         |      |       |       |       |            |          |
|*  3 |    TABLE ACCESS FULL| T    |  4583 |   572K|       |    16   (0)| 00:00:01 |
|*  4 |    TABLE ACCESS FULL| T    |     1 |   128 |       |    16   (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("X"='secooler')
   4 - filter("Y"='T')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        126  consistent gets
          0  physical reads
          0  redo size
     253890  bytes sent via SQL*Net to client
       1009  bytes received via SQL*Net from client
         49  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
       4782  rows processed

4.在没有创建索引情况下的实验结论
1)无论是返回记录多的条件放在where子句的前面还是后面,从执行计划上看,效率是一样的。
2)没有创建索引的情况下,使用UNION改写后效率没有提高,反而下降了

5.在看一下,创建所需的索引情况后的实验效果
sec@ora10g> create index idx1_t on t(x);

Index created.

sec@ora10g> create index idx2_t on t(y);

Index created.

sec@ora10g> select * from t where x = 'secooler' or y = 'T';

4782 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  4583 |   572K|    16   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  4583 |   572K|    16   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("X"='secooler' OR "Y"='T')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        111  consistent gets
          0  physical reads
          0  redo size
     206142  bytes sent via SQL*Net to client
       1009  bytes received via SQL*Net from client
         49  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4782  rows processed

sec@ora10g> select * from t where y = 'T' or x = 'secooler';

4782 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |  4583 |   572K|    16   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| T    |  4583 |   572K|    16   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("Y"='T' OR "X"='secooler')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        111  consistent gets
          0  physical reads
          0  redo size
     206142  bytes sent via SQL*Net to client
       1009  bytes received via SQL*Net from client
         49  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
       4782  rows processed

sec@ora10g> select * from t where x = 'secooler'
union
select * from t where y = 'T'
/
  2    3    4
4782 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 4276936497

------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name   | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |        |  4584 |   573K|       |   153   (3)| 00:00:02 |
|   1 |  SORT UNIQUE                  |        |  4584 |   573K|  1448K|   153   (3)| 00:00:02 |
|   2 |   UNION-ALL                   |        |       |       |       |            |          |
|*  3 |    TABLE ACCESS FULL          | T      |  4583 |   572K|       |    16   (0)| 00:00:01 |
|   4 |    TABLE ACCESS BY INDEX ROWID| T      |     1 |   128 |       |     2   (0)| 00:00:01 |
|*  5 |     INDEX RANGE SCAN          | IDX2_T |     1 |       |       |     1   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("X"='secooler')
   5 - access("Y"='T')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
         66  consistent gets
          0  physical reads
          0  redo size
     253890  bytes sent via SQL*Net to client
       1009  bytes received via SQL*Net from client
         49  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
       4782  rows processed


6.在创建所需的索引后的实验结果
1)无论是返回记录多的条件放在where子句的前面还是后面,从执行计划上看,效率还是一样的。
2)从“consistent gets”参数上看,使用UNION改写OR后,效率得到有效的提升。

7.小结
通过上面的实验,可以得到在CBO模式下,无论是返回记录多的条件放在where子句的前面还是后面,从执行计划上看,效率是一样的。
另外一个重要结论就是:在考虑使用UNION改写OR的时候,一定要注意查看使用的字段是否已经创建了索引。

分享到:
评论

相关推荐

    `人工智能_人脸识别_活体检测_身份认证`.zip

    人脸识别项目实战

    深度学习教程和开发计划.zip

    深度学习教程和开发计划.zip

    事件总线_对象C_订阅发布_消息传递中间件_1741862275.zip

    c语言学习

    基本版贪吃蛇源代码.zip

    基本版贪吃蛇源代码.zip

    【Python毕设】p107基于Django的药店信息管理-vue.zip

    项目资源包含:可运行源码+sql文件+ python3.8+django+mysql5.7+vue 适用人群:学习不同技术领域的小白或进阶学习者;可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 项目具有较高的学习借鉴价值,也可拿来修改、二次开发。 有任何使用上的问题,欢迎随时与博主沟通,博主看到后会第一时间及时解答。 Django==3.2.11 PyMySQL==1.0.2 djangorestframework==3.13.0 django-cors-headers==3.13.0 Pillow==9.1.1 psutil==5.9.4

    Abaqus螺栓拧紧过程仿真 (1)螺栓螺母可实现参数化建模,全部采用六面体C3D8R单元建模 (2)施加边界条件实现螺母的拧紧过程,输出过程动画和应力、位移参数 (3)提取螺栓中部截面的轴力和螺母

    Abaqus螺栓拧紧过程仿真 (1)螺栓螺母可实现参数化建模,全部采用六面体C3D8R单元建模 (2)施加边界条件实现螺母的拧紧过程,输出过程动画和应力、位移参数 (3)提取螺栓中部截面的轴力和螺母拧紧力矩之间的关系 ,Abaqus; 螺栓拧紧; 参数化建模; 六面体C3D8R单元建模; 边界条件; 输出动画; 应力位移参数; 轴力与拧紧力矩关系。,Abaqus螺栓拧紧仿真:六面体单元建模与力矩关系分析

    苏苏源码-weixin123-基于SpringBoot的汽车售后服务系统及微信小程序的设计与实现(编号:49000250).zip

    标题基于SpringBoot的汽车售后服务系统及微信小程序的设计与实现AI更换标题第1章引言介绍汽车售后服务的重要性,SpringBoot和微信小程序的应用背景,以及本研究的意义和目的。1.1研究背景与意义阐述汽车售后服务市场的现状及发展趋势,SpringBoot和微信小程序在售后服务中的应用前景。1.2国内外研究现状概述国内外在汽车售后服务系统和小程序开发方面的研究进展。1.3研究内容与创新点介绍本文的主要研究内容,包括系统设计和微信小程序的开发,并阐述创新点。第2章相关理论与技术介绍SpringBoot框架、微信小程序开发的相关理论和关键技术。2.1SpringBoot框架概述阐述SpringBoot框架的特点、优势以及在系统开发中的应用。2.2微信小程序开发技术介绍微信小程序的开发流程、关键技术和功能实现。2.3数据库技术与系统设计讨论数据库设计原则、数据存储和处理速度的问题,并阐述系统设计的思路和方法。第3章系统需求分析与设计对汽车售后服务系统的需求进行分析,并设计系统的整体架构和功能模块。3.1需求分析从用户角度和业务需求出发,对系统的功能需求和非功能需求进行详细分析。3.2

    智慧园区安全方案(浙江大华)PPT(69页).pptx

    在智慧园区建设的浪潮中,一个集高效、安全、便捷于一体的综合解决方案正逐步成为现代园区管理的标配。这一方案旨在解决传统园区面临的智能化水平低、信息孤岛、管理手段落后等痛点,通过信息化平台与智能硬件的深度融合,为园区带来前所未有的变革。 首先,智慧园区综合解决方案以提升园区整体智能化水平为核心,打破了信息孤岛现象。通过构建统一的智能运营中心(IOC),采用1+N模式,即一个智能运营中心集成多个应用系统,实现了园区内各系统的互联互通与数据共享。IOC运营中心如同园区的“智慧大脑”,利用大数据可视化技术,将园区安防、机电设备运行、车辆通行、人员流动、能源能耗等关键信息实时呈现在拼接巨屏上,管理者可直观掌握园区运行状态,实现科学决策。这种“万物互联”的能力不仅消除了系统间的壁垒,还大幅提升了管理效率,让园区管理更加精细化、智能化。 更令人兴奋的是,该方案融入了诸多前沿科技,让智慧园区充满了未来感。例如,利用AI视频分析技术,智慧园区实现了对人脸、车辆、行为的智能识别与追踪,不仅极大提升了安防水平,还能为园区提供精准的人流分析、车辆管理等增值服务。同时,无人机巡查、巡逻机器人等智能设备的加入,让园区安全无死角,管理更轻松。特别是巡逻机器人,不仅能进行360度地面全天候巡检,还能自主绕障、充电,甚至具备火灾预警、空气质量检测等环境感知能力,成为了园区管理的得力助手。此外,通过构建高精度数字孪生系统,将园区现实场景与数字世界完美融合,管理者可借助VR/AR技术进行远程巡检、设备维护等操作,仿佛置身于一个虚拟与现实交织的智慧世界。 最值得关注的是,智慧园区综合解决方案还带来了显著的经济与社会效益。通过优化园区管理流程,实现降本增效。例如,智能库存管理、及时响应采购需求等举措,大幅减少了库存积压与浪费;而设备自动化与远程监控则降低了维修与人力成本。同时,借助大数据分析技术,园区可精准把握产业趋势,优化招商策略,提高入驻企业满意度与营收水平。此外,智慧园区的低碳节能设计,通过能源分析与精细化管理,实现了能耗的显著降低,为园区可持续发展奠定了坚实基础。总之,这一综合解决方案不仅让园区管理变得更加智慧、高效,更为入驻企业与员工带来了更加舒适、便捷的工作与生活环境,是未来园区建设的必然趋势。

    词法分析_SysY2022_标识符字面量_错误处理器_1741862780.zip

    c语言学习

    `移动开发_人脸识别_Face++_Android项目集成`.zip

    人脸识别项目源码实战

    计算机视觉_CNN_人脸识别_训练与测试.zip

    人脸识别项目实战

    电力电子技术基础-电力电子器件与典型应用解析

    内容概要:本文详细介绍了电力电子技术的基础知识及相关器件,内容涵盖电力电子器件(如晶闸管、GTR、IGBT)、相控整流电路(单相和三相)、直流斩波电路、交流变换电路、逆变电路、软开关技术等,并探讨了其应用场景(如开关电源、不间断电源(UPS)、电子镇流器、感应加热、直流电源、开关模焊接等),以及电力电子装置带来的电力公害(谐波污染、电磁干扰和功率因数降低)及其抑制方法。通过丰富的实例讲解了各类电路的工作原理和波形分析方法,旨在让学生和从业人员更好地理解和掌握该领域的核心技术和发展趋势。书中结合最新的研究成果进行了详尽阐述,使内容兼具科学性和创新性,并提供了大量习题以便于教与学。 适合人群:自动化、电气工程及其自动化等相关专业本科生、研究生和技术工程师。 使用场景及目标:①高校教师用于课堂授课,辅助学生深入理解电力电子器件工作原理;②电力电子领域科研人员和工程技术人员参考资料,掌握行业前沿技术和设计理念。 阅读建议:本文不仅讲解了电力电子器件的结构特点、操作流程,更重要的是展示了电力电子技术在整个电力系统和电气设备应用中的关键作用,希望读者能够在学习过程中理论结合实践,加深对知识的理解

    编译技术_C语言_Clang_AST_解释执行器_作业实现辅_1741861002.zip

    c语言学习

    万能视频拼接软件源码,可以直接进行修改增加功能,二次开发!

    万能视频拼接软件源码,可以直接进行修改增加功能,二次开发!

    1. 人工智能_图像识别_CaptchaRecognise_验证码识别.zip

    人脸识别项目源码实战

    医学设备FibroScan PRO肝病检测操作与数据解析指南(可复现,有问题请联系博主)

    内容概要:本文介绍了FibroScan PRO这款专门用于肝脏纤维化程度评估的医疗器械。强调了其仅能被认证过的专员使用,所得到的数据需要专业医生综合考虑病人的实际身体状况进行精准解释。文中列举了若干组测量示例以及相关单位,例如压力数值(kPa)、声衰减参数(dB/m),还特别指出VCTE探针的正确性和精确度依靠定期校正。此外,详细阐述了病人的姿势调整以及测试部位选取的原则,在不同层厚的情况下对皮肤组织进行检查。并提供了一份详细的检查报告模板,涵盖了操作者的身份确认、受检人基本信息、时间戳以及其他一些量化评价指标,例如IQR(四分位距),这有助于更好地理解和应用FibroScan的检测结果。 适合人群:面向医院、诊所等相关医疗保健机构的工作人员,包括但不限于操作员和技术支持团队成员。同时也可以为想要了解这一先进诊断工具的研究人员或医学学生提供重要参考资料。 使用场景及目标:旨在指导医疗机构如何标准化地完成FibroScan设备的实际临床应用过程;确保所有测量数据均能在符合质量控制的前提下产生,并提高医疗服务的质量和效率;并且帮助医师做出更加科学合理的健康决策,最终服务于病患的利益最大化。

    海豚鲸鱼数据集 5435张图 正确识别率可达92.6% 可识别:海豚 虎鲸 蜥蜴 海豹 鲨鱼 龟 支持darknet格式标注

    海豚鲸鱼数据集 5435张图 正确识别率可达92.6% 可识别:海豚 虎鲸 蜥蜴 海豹 鲨鱼 龟 支持darknet格式标注

    TokenYc_FaceRecognizer_1741777923.zip

    人脸识别项目

    人脸识别_Facenet_Retinaface_Pytorc_1741770927.zip

    人脸识别项目实战

    AUTOSAR 4.4.0 最新规范文档 SWS部分

    AUTOSAR 4.4.0 最新规范文档 SWS部分

Global site tag (gtag.js) - Google Analytics