简单改写SQL达到优化目的

select *
from (select t.row_id,
t.supplier_name,
t.tel,
address,
t.contact,
t.contact_post,
t.contact_mobi,
t.contact_tel,
case
when project_supp_type = 0 then
to_number(nvl(t.discount_rate, 0))
when project_supp_type2 = 0 then
to_number(nvl(t.discount_rate2, 0))
when project_supp_type3 = 0 then
to_number(nvl(t.discount_rate3, 0))
when project_supp_type4 = 0 then
to_number(nvl(t.discount_rate4, 0))
when project_supp_type5 = 0 then
to_number(nvl(t.discount_rate5, 0))
when project_supp_type6 = 0 then
to_number(nvl(t.discount_rate6, 0))
end as rate
from md_supplier t
where t.supplier_type = 4
and (project_supp_type = 0 or project_supp_type2 = 0 or
project_supp_type3 = 0 or project_supp_type4 = 0 or
project_supp_type5 = 0 or project_supp_type6 = 0)
and t.status = 1
and exists (select *
from md_project mp, md_project_supplier mps
where mp.row_id = mps.project_id
and mp.status = 1

and supplier_id = t.row_id)
order by rate desc, t.supplier_name)
where rownum <= 5

这是原始sql,sql运行4秒出结果,网友反映比较慢

看了执行计划

执行计划没有问题,驱动表全表扫描也只是返回27条,无伤大雅,被驱动表view VW_SQ_1

被驱动表内走了 merge jion,merge jion比nl要强一下,进行全表扫描之后再排序,之后再连接

问题要看exists中的表 返回227行,在view中 exists中的表有相当于一个驱动表了,他要驱动id 10,每次查询都要全表 ,还要227次,就慢了,就需要改写

将它提取出来,不让他扫描多次,这就是思路

改写之后的sql

with ttt as (select *
                    from md_project mp, md_project_supplier mps
                   where mp.row_id = mps.project_id
                     and mp.status = 1
)
select *
    from (select t.row_id,
                 t.supplier_name,
                 t.tel,
                 address,
                 t.contact,
                 t.contact_post,
                 t.contact_mobi,
                 t.contact_tel,
                 case
                   when project_supp_type = 0 then
                    to_number(nvl(t.discount_rate, 0))
                   when project_supp_type2 = 0 then
                    to_number(nvl(t.discount_rate2, 0))
                   when project_supp_type3 = 0 then
                    to_number(nvl(t.discount_rate3, 0))
                   when project_supp_type4 = 0 then
                    to_number(nvl(t.discount_rate4, 0))
                   when project_supp_type5 = 0 then
                    to_number(nvl(t.discount_rate5, 0))
                   when project_supp_type6 = 0 then
                    to_number(nvl(t.discount_rate6, 0))
                 end as rate
            from md_supplier t
           where t.supplier_type = 4
             and (project_supp_type = 0 or project_supp_type2 = 0 or
                 project_supp_type3 = 0 or project_supp_type4 = 0 or
                 project_supp_type5 = 0 or project_supp_type6 = 0)
             and t.status = 1
             and exists (select * from ttt where supplier_id = t.row_id)
           order by rate desc, t.supplier_name)
   where rownum <= 5

sql运行时间为0.03秒

时间: 2024-11-09 03:02:08

简单改写SQL达到优化目的的相关文章

深入浅出数据仓库中SQL性能优化之Hive篇

转自:http://www.csdn.net/article/2015-01-13/2823530 一个Hive查询生成多个Map Reduce Job,一个Map Reduce Job又有Map,Reduce,Spill,Shuffle,Sort等多个阶段,所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR Job)的优化,下文会分别阐述. 在开始之前,先把MR的流程图帖出来(摘自Hadoop权威指南),方便后面对照.另

数据仓库中的 SQL 性能优化(Hive篇)

一个Hive查询生成多个map reduce job,一个map reduce job又有map,reduce,spill,shuffle,sort等多个阶段,所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化(其中又会有细分),针对MR全局的优化,和针对整个查询(多MR job)的优化,下文会分别阐述. 在开始之前,先把MR的流程图帖出来(摘自Hadoop权威指南),方便后面对照.另外要说明的是,这个优化只是针对Hive 0.9版本,而不是后来Hortonwork发起Stinger

SQL性能优化前期准备-清除缓存、开启IO统计

如果需要进行SQl Server下的SQL性能优化,需要准备以下内容: 一.SQL查询分析器设置: 1.开启实际执行计划跟踪. 2.每次执行需优化SQL前,带上清除缓存的设置SQL. 平常在进行SQL Server性能优化时,为了确保真实还原性能问题,我们需要关闭SQL Server自身的执行计划及缓存.可以通过以下设置清除缓存. 1 DBCC DROPCLEANBUFFERS --清除缓冲区 2 DBCC FREEPROCCACHE --删除计划高速缓存中的元素 3.开启查询IO读取统计.查询

从案例中学习SQL数据库优化

下载地址:百度网盘下载 课程目录: 1.从案例中推导SQL优化的总体思路与误区2.从案例中分析体系结构如何左右SQL性能3.从案例中体验逻辑结构如何影响SQL优化4.从案例中探寻表设计对SQL优化的重要性5.从案例中明白索引是如何让SQL运行飞快6.从案例中体会索引让SQL举步维艰的一面7.从案例中体会函数及位图索引与SQL优化8.从案例中洞察表连接与SQL优化之间关系9.从案例中探讨该如何分析读懂析执行计划10.从案例中弄清如何正确选择SQL性能工具11.从案例中学习如何进行不改写SQL的优化

SQL Server SQL性能优化之--数据库在“简单”参数化模式下,自动参数化SQL带来的问题

数据库参数化的模式 数据库的参数化有两种方式,简单(simple)和强制(forced),默认的参数化默认是“简单”,简单模式下,如果每次发过来的SQL,除非完全一样,否则就重编译它(特殊情况会自动参数化,正是本文想说的重点)强制模式就是将adhoc SQL强制参数化,避免每次运行的时候因为参数值的不同而重编译,这里不详细说明. 这首先要感谢“潇湘隐者”大神的提示, 当时也是遇到一个实际问题, 发现执行计划对数据行的预估,怎么都不对,有观察到无论怎么改变参数,SQL语句执行前都没有重编译,疑惑了

转:sql语句优化

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

SQL语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜. 连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行.

sql语句优化SQL Server

MS   SQL   Server查询优化方法查询速度慢的原因很多,常见如下几种 1.没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)          2.I/O吞吐量小,形成了瓶颈效应.          3.没有创建计算列导致查询不优化.          4.内存不足          5.网络速度慢          6.查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)          7.锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)   

[转]sql语句优化原则

性能不理想的系统中除了一部分是因为应用程序的负载确实超过了服务器的实际处理能力外,更多的是因为系统存在大量的SQL语句需要优化. 为了获得稳定的执行性能,SQL语句越简单越好.对复杂的SQL语句,要设法对之进行简化. 常见的简化规则如下: 1)不要有超过5个以上的表连接(JOIN)2)考虑使用临时表或表变量存放中间结果.3)少用子查询4)视图嵌套不要过深,一般视图嵌套不要超过2个为宜.  连接的表越多,其编译的时间和连接的开销也越大,性能越不好控制. 最好是把连接拆开成较小的几个部分逐个顺序执行