SQL优化实例

示例一:hint滥用

select /*+ ordered use_nl(b a c d)*/
       *
  from b,a,c,d
 where b.col1 = a.col1
   and a.col2 = c.col2
   and a.col3 = d.col3
   and a.dt  >= to_date('20010101 00:00:00','YYYYMMDD HH24:MI:SS')
   and a.dt <   to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')

分析:
1)表之间的关系:
2)数据量,索引情况   b 200万,a 200万 ,过滤后50行,c 200行, d 1000行
3)优化器模式  RBO  or  CBO
4)不同的优化器模式采用不用的优化策略

优化措施:---》
对于CBO,把添加的hint去掉就可以了,Oracle会根据数据量和索引情况生成高效的执行计划
select *
  from b,a,c,d
 where b.col1 = a.col1
   and a.col2 = c.col2
   and a.col3 = d.col3
   and a.dt  >= to_date('20010101 00:00:00','YYYYMMDD HH24:MI:SS')
   and a.dt <   to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')

--------------------------------------------------------------

示例二:多余的表或列访问

select a.col1,b.col2,a.dt
  from a,c,b
 where a.col1 =  c.col1
   and c.col1 = b.col1
   and a.dt  >= to_date('20010101 00:00:00','YYYYMMDD HH24:MI:SS')
   and a.dt < to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')

分析:
1)表之间的关系 a,c 1:1  c,b 1:1
2)select里没有出现c表的列,此时可以考虑c表是否是必须的
3)如果分析表之间的关系及数据的特点发现c表不是必须的,可以去掉c表的访问
4)说明:当然也有些情况下c表可能是必须的,具体情况具体分析

优化措施:--》
如果经过分析发现c表的访问确实是多余的,那么上述语句可以改为:
select a.col1,b.col2,a.dt
  from a,b
 where a.col1 = b.col1
   and a.dt  >= to_date('20010101 00:00:00','YYYYMMDD HH24:MI:SS')
   and a.dt < to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')

select col1,col2,dt
  from
(
select a.*,b.col2,a.rownum rn
  from a,b
 where a.col1 = b.col1
   and a.dt  >= to_date('20010101 00:00:00','YYYYMMDD HH24:MI:SS')
   and a.dt < to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')
   order by a.col1
)
where rn between 10 and 20

分析:
1)内层查询使用a.*,而外层只需要a的col1这一列,所以把内层查询的c.*具体化,减少资源和时间的消耗

优化措施:--》
select col1,col2,dt
  from
(
select a.col1,b.col2,a.rownum rn
  from a,b
 where a.col1 = b.col1
   and a.dt  >= to_date('20010101 00:00:00','YYYYMMDD HH24:MI:SS')
   and a.dt < to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')
   order by a.col1
)
where rn between 10 and 20

--------------------------------------------------------

示例三:索引使用的灵活处理

select a.dt,b.timezone,a.col1,a.col2,a.col3
  from a,b
 where a.col1 = b.col1
   and a.dt   >= to_date('20010101 00:00:00','YYYYMMDD 24:MI:SS') - b.timezone
   and a.dt   < to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS') -b.timezone
保证同一时间段统计

分析:
1)表之间的关系:
2)数据量,索引情况 a 100万  b 200    a.dt有索引, a.col1,b.col1有索引
3)条件中a.dt列的比较范围是变化的,所以导致dt列的索引无法使用
4)分析b.timezone的数值范围,在-12:00~12:00之间
5)为了使用a.dt列的索引,考虑可以把a.dt的范围条件放大到固定值,然后再对结果集进行过滤。

优化措施:--》

select *
from
(
select a.dt,b.timezone,a.col1,a.col2,a.col3
  from a,b
 where a.col1 = b.col1
   and a.dt   >= to_date('20010101 00:00:00','YYYYMMDD 24:MI:SS') -1
   and a.dt  < to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')+1
) ab

   where ab.dt   >= to_date('20010101 00:00:00','YYYYMMDD 24:MI:SS') -ab.timezone
   and ab.dt  < to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')- ab.timezone

----------------------------------------------------------

示例四:有没有合适的索引可用

select a.col1,a.col2,a.col3,b.col4,c.col5
  from a,b,c
 where a.col1 = b.col1
   and a.col2 = b.col2
   and a.col3 = c.col3
   and a.dt  >= to_date('20010101 00:00:00','YYYYMMDD HH24:MI:SS')
   and a.dt < to_date('20010102 00:00:00','YYYYMMDD HH24:MI:SS')

分析:
1)表之间的关系
2)数据量,索引情况   a.dt, b.col1, b.col2, c.col3列分别有索引
3)但是单独使用b.col1列的索引或者b.col2列的索引,数据筛选效果都不好
4)这样考虑为b表的col1,col2创建联合索引

优化措施:--》
为b表的col1,col2列创建联合索引

------------------------------------------------------

示例五:不必要的外连接

select a.col1,b.col2,b.col3
  from a,b
 where a.col1 = b.col2(+)
   and b.col3 > 1000

分析:
1)条件b.col3>1000意味着原本使用外连接多出来的列要被排除掉,所以此处外连接是不需要的

优化措施:--》

select a.col1,b.col2,b.col3
  from a,b
 where a.col1 = b.col2
   and b.col3 > 1000

-----------------------------------------------------

示例六:with子句的使用

select ab.col1,ab.col3,c.col2
  from c,
(
select a.col1,b.col3
  from a,b
 where a.col1 = b.col1
   and b.col3 > 1000
) ab
where c.col1 = ab.col1
union
select ab.col1,ab.col3,d.col2
  from d,
(
select a.col1,b.col3
  from a,b
 where a.col1 = b.col1
   and b.col3 > 1000
) ab
where d.col1 = ab.col1

分析:
1)该语句中出现了多处相同的子查询,可以使用with子句来进行简化,减少数据访问,提高效率

优化措施:--》
with ab as
(
select a.col1,b.col3
  from a,b
 where a.col1 = b.col1
   and b.col3 > 1000
)
select ab.col1,ab.col3,c.col2
  from c,ab
where c.col1 = ab.col1
union
select ab.col1,ab.col3,d.col2
  from d,ab
where d.col1 = ab.col1

时间: 2024-08-01 01:27:38

SQL优化实例的相关文章

mysql sql优化实例

mysql sql优化实例 优化前: pt-query-degist分析结果: # Query 3: 0.00 QPS, 0.00x concurrency, ID 0xDC6E62FA021C85B5 at byte 628331 # This item is included in the report because it matches --limit. # Scores: V/M = 0.19 # Time range: 2016-09-24T15:14:24 to 2016-10-0

SQL优化实例-思路分析

一SQL优化思路 一个真实具体的SQL优化思路 一般都看预估的执行计划,比如遇到一个sql执行计划很长,很复杂,从计划中没有看到返回行数多,cost高或连接方式错误的地方,没有明显瓶颈,但整体逻辑读很高,运行很慢.这时就可以去看真实的执行计划,并查看真实计划里逻辑读cr最多的步骤.可以做个10046.根据逻辑读最多的步骤判断对应连接方式,比如这里nest loop 的cr最大,且对应俩大结果集.显然有问题.于是再根据预估的执行计划判断俩表的连接方式.预估计划是164 :1结果集,那根据对应查询条

走在专家的路上,每天一条SQL优化(3)

本系列分享的SQL优化实例,并不一定适用于所有相似SQL或所有场景.我们只是介绍一种方法,当你再次遇到类似SQL,可以根据真实场景,选择最适合的方案.另外,有疑问的时候,最好的办法就是测试,动手才能找到最佳答案! SQL文本如下: SELECT NVL(SUM(SRE), 0) HRJE FROM MD3U.CARD_INCOME A WHERE YLGRZHH = '371081110630214389' AND DDQCSRH IS NULL AND ZDLSH IS NOT NULL AN

基于CBO的SQL优化和Oracle实例优化

作者:朱培 ID:sdksdk0 SQL优化是数据优化的重要方面,本文将分析Oracle自身的CBO优化,即基于成本的优化方法.Oracle为了自动的优化sql语句需要各种统计数据作为优化基础.外面会通过sql的追踪来分析sql的执行过程,消耗的资源信息.对于数据库的性能问题往往是在系统部署一段时间之后出现的,即大量用户开始使用该系统,系统的数据处理量和各种计算复杂性增加的时候,这个时候往往会追溯到系统的初始设计阶段,所以我们还是要在编码阶段就编写高效的sql语句.我在网上看到了很多关于sql优

(Oralce) Web翻页优化实例

web|翻页|优化 Web翻页优化实例 作者:Wanghai 环境: Linux version 2.4.20-8custom (root@web2) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #3 SMP Thu Jun 5 22:03:36 CST 2003 Mem: 2113466368 Swap: 4194881536 CPU:两个超线程的Intel(R) Xeon(TM) CPU 2.40GHz 优化前语句在mysql里面

阿里云慢SQL优化挑战大赛分析

[背景] 阿里云慢SQL优化挑战赛:https://yq.aliyun.com/articles/136363?spm=5176.100240.searchblog.32.oYlhtr [考点分析] 本次慢SQL优化挑战赛的题目全部来自于生产案例,将众多考察点揉合到一条SQL中,主要考虑了以下方面: 表设计:考察字符和数字字段定义,字符集大小写校验,时间字段存储. 驱动表:考察多表join时候最优的连接顺序. 索引优化:考察索引消除排序以,索引隐式转换,覆盖索引避免回表的问题. 执行计划:使用e

掌握SQL Monitoring这些特性,SQL优化通通不在话下

目录 术语说明 概述 什么SQL会被SQL MONITORING监控到 找到Real Time SQL Monitoring入口 详解Real Time SQL Monitoring     1术语说明   在正式介绍Real Time SQL Monitoring之前,我们先对接下来要用到一些术语做集中的介绍.   Table Queue,消息缓冲区,在并行操作中使用,用于PX进程之间的通信,或者PX进程与QC进程之间的通信,是内存中的一些page,每个消息缓冲区的大小由参数parallel_

CloudDBA最佳实践-TOP SQL优化分析数据库性能问题

    云数据库CloudDBA诊断报告的TOP SQL优化是非常实用的功能,我们可以通过TOP SQL去诊断数据库中各种问题,比如性能出现下降,数据库压力出现波动,下面介绍两个线上生产案例.     一. 利用CloudDBA TOP SQL找出数据库规格升级而性能下降的元凶     最近在协助用户进行系统重构,RDS测试选型自然成为了本项目的一个重点,但是用户在测试不同规格的时候发现大规格的实例性能居然不如小规格,4C32G规格性能比8C64G规格高出10%,其性能监控也是非常的正常,4C3

CloudDBA初体验:SQL优化建议

数据库诊断和优化过程具有相当的复杂性,通常需要专业的DBA来解决.但在云计算的今天,人力运维和支撑已经变得不可能,自动化,智能化运维和服务支持日益迫切. 阿里云数据库团队在这方面不断的探索和积累,产出了CloudDBA.其目的就是要把我们已知问题和最佳实践能够以最简单的方式告诉用户,把我们多年使用数据库的经验传承给用户,方便客户使用云上数据库,给客户带来直接的价值.CloudDBA同时也在服务着内部业务,4000+的数据库实例之前需要一个team的运维人员,到现在我们只有一个同学,运维效率大幅提