关于一个sql的优化分析

应用这边新上线了一个查询，正在跑，让我看下状态以及分析下能不能再快点。

如下sql:

SELECT x.order_no ,
order_date+7/24 AS order_date,
address
||
district AS ADDRESS,
city ,
extn_style_number
||
‘-‘
||
extn_color_number ,
SUM(line_total) ,
SUM(ORDERED_QTY) ,
CASE
WHEN division=‘55‘
THEN ‘SWOOSH‘
ELSE ‘‘
END AS SWOOSH,
CASE
WHEN lower (MRKTNG_CHNNL_ORDR_EXTN_MV.LAST_TOUCH_TRACKING_CODE) LIKE ‘%cnns_ksk%‘
THEN ‘SEAMLESS‘
ELSE ‘‘
END AS SEAMLESS,
CASE
WHEN line_type=‘NIKEID‘
THEN ‘NIKEID‘
ELSE ‘‘
END AS NIKEID
FROM
(
SELECT DISTINCT l.line_type ,
s.status ,
order_DATE ,
order_no ,
retail_price ,
ORDERED_QTY ,
division ,
l.line_total ,
l.item_description ,
l.extn_size_description ,
l.extn_style_number ,
l.extn_color_number ,
l.list_price ,
pp.address_line1 AS address ,
pp.address_line4 AS district,
pp.city
FROM dom.yfs_order_header h ,
dom.yfs_ordeR_line l ,
dom.yfs_order_release_status s,
dom.yfs_person_info pp
WHERE h.order_header_key = l.order_header_key
AND l.order_line_key = s.order_line_key
AND pp.person_info_key = h.bill_to_key
AND h.enterprise_key = ‘NIKECN‘
AND s.status_quantity > 0
AND document_type = ‘0001‘
AND l.LINE_TOTAL >0
AND s.status <> ‘9000‘
AND h.division IN (‘55‘,‘400‘)
AND order_date +7/24 >= to_date(‘01-Jun-15‘,‘DD-MON-YY‘)
AND order_date +7/24 < to_date(‘01-Nov-15‘,‘DD-MON-YY‘)
AND h.order_type <>‘legacy‘
AND
(
order_purpose <>‘REFUND‘
OR order_purpose IS NULL
)
AND
(
ORDER_TYPE <>‘ProductVoucher‘
OR ORDER_TYPE IS NULL
)
)
X
LEFT OUTER JOIN NTCOM.MRKTNG_CHNNL_ORDR_EXTN_MV MRKTNG_CHNNL_ORDR_EXTN_MV
ON X.ORDER_NO=MRKTNG_CHNNL_ORDR_EXTN_MV.ORDER_NO
GROUP BY x.order_no ,
order_date+7/24,
address
||
district,
city ,
extn_style_number
||
‘-‘
||
extn_color_number,
CASE
WHEN division=‘55‘
THEN ‘SWOOSH‘
ELSE ‘‘
END,
CASE
WHEN lower (MRKTNG_CHNNL_ORDR_EXTN_MV.LAST_TOUCH_TRACKING_CODE) LIKE ‘%cnns_ksk%‘
THEN ‘SEAMLESS‘
ELSE ‘‘
END,
CASE
WHEN line_type=‘NIKEID‘
THEN ‘NIKEID‘
ELSE ‘‘
END
UNION ALL
SELECT y.order_no ,
order_date+7/24 AS order_date,
address
||
district AS ADDRESS,
city ,
extn_style_number
||
‘-‘
||
extn_color_number ,
SUM(line_total) ,
SUM(ORDERED_QTY) ,
CASE
WHEN division=‘55‘
THEN ‘SWOOSH‘
ELSE ‘‘
END AS SWOOSH,
CASE
WHEN lower (MRKTNG_CHNNL_ORDR_EXTN_MV.LAST_TOUCH_TRACKING_CODE) LIKE ‘%cnns_ksk%‘
THEN ‘SEAMLESS‘
ELSE ‘‘
END AS SEAMLESS,
CASE
WHEN line_type=‘NIKEID‘
THEN ‘NIKEID‘
ELSE ‘‘
END AS NIKEID
FROM
(
SELECT DISTINCT l.line_type ,
s.status ,
order_DATE ,
order_no ,
retail_price ,
ORDERED_QTY ,
division ,
l.line_total ,
l.item_description ,
l.extn_size_description ,
l.extn_style_number ,
l.extn_color_number ,
l.list_price ,
pp.address_line1 AS address ,
pp.address_line4 AS district,
pp.city
FROM dom.yfs_order_header_H h ,
dom.yfs_ordeR_line_H l ,
dom.yfs_order_release_status_H s,
dom.yfs_person_info pp
WHERE h.order_header_key = l.order_header_key
AND l.order_line_key = s.order_line_key
AND pp.person_info_key = h.bill_to_key
AND h.enterprise_key = ‘NIKECN‘
AND s.status_quantity > 0
AND document_type = ‘0001‘
AND l.LINE_TOTAL >0
AND s.status <> ‘9000‘
AND h.division IN (‘55‘,‘400‘)
AND order_date +7/24 >= to_date(‘01-Jun-15‘,‘DD-MON-YY‘)
AND order_date +7/24 < to_date(‘01-Nov-15‘,‘DD-MON-YY‘)
AND h.order_type <>‘legacy‘
AND
(
order_purpose <>‘REFUND‘
OR order_purpose IS NULL
)
AND
(
ORDER_TYPE <>‘ProductVoucher‘
OR ORDER_TYPE IS NULL
)
)
Y
LEFT OUTER JOIN NTCOM.MRKTNG_CHNNL_ORDR_EXTN_MV MRKTNG_CHNNL_ORDR_EXTN_MV
ON Y.ORDER_NO=MRKTNG_CHNNL_ORDR_EXTN_MV.ORDER_NO
GROUP BY 1,2,3,4，......；

大致的结构就是两个select语句做union的操作

一个select现在的表，一个select历史表

来继续看下执行计划，

-----------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 227K(100)| |
| 1 | UNION-ALL | | | | | |
| 2 | HASH GROUP BY | | 169 | 24674 | 93719 (1)| 00:35:56 |
|* 3 | HASH JOIN OUTER | | 169 | 24674 | 93718 (1)| 00:35:56 |
| 4 | VIEW | | 169 | 17914 | 20470 (1)| 00:07:51 |
| 5 | HASH UNIQUE | | 169 | 53235 | 20470 (1)| 00:07:51 |
|* 6 | FILTER | | | | | |
| 7 | NESTED LOOPS | | 169 | 53235 | 20469 (1)| 00:07:51 |
| 8 | NESTED LOOPS | | 846 | 53235 | 20469 (1)| 00:07:51 |
| 9 | NESTED LOOPS | | 94 | 26226 | 19659 (1)| 00:07:33 |
| 10 | NESTED LOOPS | | 50 | 8100 | 19428 (1)| 00:07:27 |
|* 11 | TABLE ACCESS BY INDEX ROWID| YFS_ORDER_HEADER | 50 | 4900 | 19278 (1)| 00:07:24 |
|* 12 | INDEX RANGE SCAN | YFS_ORDER_HEADER_I2 | 1151 | | 18386 (1)| 00:07:03 |
| 13 | TABLE ACCESS BY INDEX ROWID| YFS_PERSON_INFO | 1 | 64 | 3 (0)| 00:00:01 |
|* 14 | INDEX UNIQUE SCAN | YFS_PERSON_INFO_PK | 1 | | 2 (0)| 00:00:01 |
|* 15 | TABLE ACCESS BY INDEX ROWID | YFS_ORDER_LINE | 2 | 234 | 6 (0)| 00:00:01 |
|* 16 | INDEX RANGE SCAN | YFS_ORDER_LINE_I1 | 3 | | 3 (0)| 00:00:01 |
|* 17 | INDEX RANGE SCAN | YFS_ORDER_RELEASE_STATUS_I2 | 9 | | 3 (0)| 00:00:01 |
|* 18 | TABLE ACCESS BY INDEX ROWID | YFS_ORDER_RELEASE_STATUS | 2 | 72 | 11 (0)| 00:00:01 |
| 19 | MAT_VIEW ACCESS FULL | MRKTNG_CHNNL_ORDR_EXTN_MV | 41M| 1590M| 73144 (1)| 00:28:03 |
| 20 | HASH GROUP BY | | 1591 | 231K| 133K (1)| 00:51:21 |
|* 21 | HASH JOIN OUTER | | 1591 | 231K| 133K (1)| 00:51:21 |
| 22 | VIEW | | 1591 | 169K| 60705 (1)| 00:23:17 |
| 23 | HASH UNIQUE | | 1591 | 531K| 60705 (1)| 00:23:17 |
|* 24 | FILTER | | | | | |
| 25 | NESTED LOOPS | | 1591 | 531K| 60704 (1)| 00:23:17 |
| 26 | NESTED LOOPS | | 1591 | 531K| 60704 (1)| 00:23:17 |
| 27 | NESTED LOOPS | | 1591 | 461K| 54351 (1)| 00:20:51 |
| 28 | NESTED LOOPS | | 477 | 85860 | 52237 (1)| 00:20:02 |
|* 29 | TABLE ACCESS BY INDEX ROWID| YFS_ORDER_HEADER_H | 477 | 55332 | 50806 (1)| 00:19:29 |
|* 30 | INDEX RANGE SCAN | YFS_ORDER_HEADER_H_I2 | 12374 | | 38482 (1)| 00:14:46 |
| 31 | TABLE ACCESS BY INDEX ROWID| YFS_PERSON_INFO | 1 | 64 | 3 (0)| 00:00:01 |
|* 32 | INDEX UNIQUE SCAN | YFS_PERSON_INFO_PK | 1 | | 2 (0)| 00:00:01 |
|* 33 | TABLE ACCESS BY INDEX ROWID | YFS_ORDER_LINE_H | 3 | 351 | 6 (0)| 00:00:01 |
|* 34 | INDEX RANGE SCAN | YFS_ORDER_LINE_H_I1 | 4 | | 3 (0)| 00:00:01 |
|* 35 | INDEX RANGE SCAN | YFS_ORDER_RELEASE_STATUS_H_I2 | 1 | | 3 (0)| 00:00:01 |
|* 36 | TABLE ACCESS BY INDEX ROWID | YFS_ORDER_RELEASE_STATUS_H | 1 | 45 | 4 (0)| 00:00:01 |
| 37 | MAT_VIEW ACCESS FULL | MRKTNG_CHNNL_ORDR_EXTN_MV | 41M| 1590M| 73144 (1)| 00:28:03 |
-----------------------------------------------------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

1 - SET$1
2 - SEL$97EC0181
4 - SEL$7C87FA5C / [email protected]$2
5 - SEL$7C87FA5C
11 - SEL$7C87FA5C / [email protected]$4
12 - SEL$7C87FA5C / [email protected]$4
13 - SEL$7C87FA5C / [email protected]$3
14 - SEL$7C87FA5C / [email protected]$3
15 - SEL$7C87FA5C / [email protected]$5
16 - SEL$7C87FA5C / [email protected]$5
17 - SEL$7C87FA5C / [email protected]$3
18 - SEL$7C87FA5C / [email protected]$3
19 - SEL$97EC0181 / [email protected]$1
20 - SEL$6FC1811E
22 - SEL$A5E413B3 / [email protected]$8
23 - SEL$A5E413B3
29 - SEL$A5E413B3 / [email protected]$10
30 - SEL$A5E413B3 / [email protected]$10
31 - SEL$A5E413B3 / [email protected]$9
32 - SEL$A5E413B3 / [email protected]$9
33 - SEL$A5E413B3 / [email protected]$11
34 - SEL$A5E413B3 / [email protected]$11
35 - SEL$A5E413B3 / [email protected]$9
36 - SEL$A5E413B3 / [email protected]$9
37 - SEL$6FC1811E / [email protected]$7

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

3 - access("X"."ORDER_NO"="MRKTNG_CHNNL_ORDR_EXTN_MV"."ORDER_NO")
6 - filter(TO_DATE(‘01-Nov-15‘,‘DD-MON-YY‘)>TO_DATE(‘01-Jun-15‘,‘DD-MON-YY‘))
11 - filter((INTERNAL_FUNCTION("DIVISION") AND ("ORDER_PURPOSE" IS NULL OR "ORDER_PURPOSE"<>‘REFUND‘) AND
"ORDER_TYPE"<>‘ProductVoucher‘ AND "ORDER_TYPE"<>‘legacy‘))
12 - access("DOCUMENT_TYPE"=‘0001‘ AND "ENTERPRISE_KEY"=‘NIKECN‘)
filter((INTERNAL_FUNCTION("ORDER_DATE")+.2916666666666666666666666666666666666667>=TO_DATE(‘01-Jun-15‘,‘
DD-MON-YY‘) AND INTERNAL_FUNCTION("ORDER_DATE")+.2916666666666666666666666666666666666667<TO_DATE(‘01-Nov-15‘,‘
DD-MON-YY‘)))
14 - access("PP"."PERSON_INFO_KEY"="BILL_TO_KEY")
15 - filter("LINE_TOTAL">0)
16 - access("ORDER_HEADER_KEY"="ORDER_HEADER_KEY")
17 - access("ORDER_LINE_KEY"="S"."ORDER_LINE_KEY")
18 - filter(("S"."STATUS_QUANTITY">0 AND "S"."STATUS"<>‘9000‘))
21 - access("Y"."ORDER_NO"="MRKTNG_CHNNL_ORDR_EXTN_MV"."ORDER_NO")
24 - filter(TO_DATE(‘01-Nov-15‘,‘DD-MON-YY‘)>TO_DATE(‘01-Jun-15‘,‘DD-MON-YY‘))
29 - filter((INTERNAL_FUNCTION("DIVISION") AND "ORDER_TYPE"<>‘ProductVoucher‘ AND ("ORDER_PURPOSE" IS NULL
OR "ORDER_PURPOSE"<>‘REFUND‘) AND "ORDER_TYPE"<>‘legacy‘))
30 - access("DOCUMENT_TYPE"=‘0001‘ AND "ENTERPRISE_KEY"=‘NIKECN‘)
filter((INTERNAL_FUNCTION("ORDER_DATE")+.2916666666666666666666666666666666666667>=TO_DATE(‘01-Jun-15‘,‘
DD-MON-YY‘) AND INTERNAL_FUNCTION("ORDER_DATE")+.2916666666666666666666666666666666666667<TO_DATE(‘01-Nov-15‘,‘
DD-MON-YY‘)))
32 - access("PP"."PERSON_INFO_KEY"="BILL_TO_KEY")
33 - filter("LINE_TOTAL">0)
34 - access("ORDER_HEADER_KEY"="ORDER_HEADER_KEY")
35 - access("ORDER_LINE_KEY"="S"."ORDER_LINE_KEY")
36 - filter(("S"."STATUS"<>‘9000‘ AND "S"."STATUS_QUANTITY">0))

======================

在做了稍微的分析，得出如下三点可以改进的意见：

1.看了下原始sql的执行计划，里面有filter的步骤，如下：

AND order_date  +7/24      >= to_date(‘01-Dec-14‘,‘DD-MON-YY‘)

AND order_date   +7/24      < to_date(‘01-Jun-15‘,‘DD-MON-YY‘)

Predicate Information (identified by operation id):

filter((INTERNAL_FUNCTION("ORDER_DATE")+.2916666666666666666666666666666666666667>=TO_DATE(‘01-Jun-15‘,‘DD-MON-YY‘) AND

INTERNAL_FUNCTION("ORDER_DATE")+.2916666666666666666666666666666666666667<TO_DATE(‘01-Nov-15‘,‘DD-MON-YY‘)))

于是想着应该这样写，可以走索引：

AND order_date        >= to_date(‘01-Dec-14‘,‘DD-MON-YY‘)-7/24

AND order_date         < to_date(‘01-Jun-15‘,‘DD-MON-YY‘)-7/24

改成这样之后的执行计划：

10 - access("DOCUMENT_TYPE"=‘0001‘ AND "H"."ENTERPRISE_KEY"=‘NIKECN‘ AND "ORDER_DATE">=TO_DATE(‘01-Dec-14‘,‘DD-MON-YY‘)-.291666666666666666666666666666

6666666667 AND "ORDER_DATE"<TO_DATE(‘01-Jun-15‘,‘DD-MON-YY‘)-.2916666666666666666666666666666666666667)

当然为什么写7/24，因为这里的日期没有小时，也不知道app的人怎么想的，如下：

SQL> select to_date(‘01-Dec-14‘,‘DD-MON-YY‘) from dual;

01-DEC-14

SQL> select to_date(‘01-Dec-14‘,‘DD-MON-YY‘)-7/24 from dual;

30-NOV-14

SQL> select to_date(‘01-Dec-14‘,‘DD-MON-YY‘)-1 from dual;

30-NOV-14

因为to_date这里只有DD-MON-YY格式

2.这个sql是两个select分别去join一张物化视图，然后再去union all

为何不先union all再去join物化视图呢，这样可以减少一次物化视图的扫描。

原始的执行计划如下：

===================================================================================================================================================================================================================================

| Id    |                Operation                |             Name              | 
Rows   | Cost  |   Time    | Start 
| Execs |   Rows   | Read 
| Read  | Mem | Activity |             Activity Detail         | Progress |

|       |                                         |                               | (Estim) |       | Active(s) | Active |       | (Actual) | Reqs  | Bytes |    
|   (%)    |               (# samples)           |          |

===================================================================================================================================================================================================================================

|  -> 0 | SELECT STATEMENT                        |                               |         |      
|      1610 |    +84 |    
1 |    86400 |       |      
|     |          |                            |   |

|  -> 1 |   UNION-ALL                             |                               |         |      
|      1610 |    +84 |    
1 |    86400 |       |      
|     |          |

19 |     
MAT_VIEW ACCESS FULL              
| MRKTNG_CHNNL_ORDR_EXTN_MV    
|     42M | 73144 |        17 |   
+68 |     1 |      42M | 
2854 |   3GB

37 |      MAT_VIEW ACCESS FULL               | MRKTNG_CHNNL_ORDR_EXTN_MV     |    
42M | 73144 |        37 |  +1456 |    
1 |      42M |  2852 |  
3GB |

可以看到第19步和第37步都做了物化视图的全扫描，最后才去union
all

所以可以改成两个select语句先去union
all再去join这个物化视图

3.物化视图的索引没用上

可以看到物化视图走的是全表扫描这样的执行计划，但是check一下上面是有索引的，

连接条件如下

LEFT OUTER JOIN
NTCOM.MRKTNG_CHNNL_ORDR_EXTN_MV MRKTNG_CHNNL_ORDR_EXTN_MV   ON     
X.ORDER_NO=MRKTNG_CHNNL_ORDR_EXTN_MV.ORDER_NO

select table_name, owner,num_rows, blocks,
last_analyzed,partitioned

from dba_tables

where table_name =‘MRKTNG_CHNNL_ORDR_EXTN_MV‘;

MRKTNG_CHNNL_ORDR_EXTN_MV      NTCOM                            41692893     362436 24-DEC-16 NO

select table_name, index_name, column_name,
column_position

from dba_ind_columns

where table_name =‘MRKTNG_CHNNL_ORDR_EXTN_MV‘

order by 1, 2, 4;

TABLE_NAME                     INDEX_NAME                     COLUMN_NAME                              COLUMN_POSITION

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

MRKTNG_CHNNL_ORDR_EXTN_MV      I_SNAP$_MRKTNG_CHNNL_ORDR_     SYS_NC00024$                                           1

MRKTNG_CHNNL_ORDR_EXTN_MV      I_SNAP$_MRKTNG_CHNNL_ORDR_     SYS_NC00025$                                           2

MRKTNG_CHNNL_ORDR_EXTN_MV      I_SNAP$_MRKTNG_CHNNL_ORDR_     SYS_NC00026$                                           3

MRKTNG_CHNNL_ORDR_EXTN_MV      I_SNAP$_MRKTNG_CHNNL_ORDR_     SYS_NC00027$                                           4

select TABLE_NAME,COLUMN_NAME,COLUMN_ID
from dba_tab_cols where table_name=‘MRKTNG_CHNNL_ORDR_EXTN_MV‘;

TABLE_NAME                     COLUMN_NAME                               COLUMN_ID

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

MRKTNG_CHNNL_ORDR_EXTN_MV      ORDER_REPORT_DT_DIM_ID                            4

MRKTNG_CHNNL_ORDR_EXTN_MV      LAST_TOUCH_TRACKING_CODE                          3

MRKTNG_CHNNL_ORDR_EXTN_MV      GEO_KEY                                           2

MRKTNG_CHNNL_ORDR_EXTN_MV      ORDER_NO                                          1

select index_type from dba_indexes where
table_name =‘MRKTNG_CHNNL_ORDR_EXTN_MV‘;

INDEX_TYPE

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

FUNCTION-BASED NORMAL

select table_name, column_name,
num_distinct, histogram

from dba_tab_col_statistics

where table_name =‘MRKTNG_CHNNL_ORDR_EXTN_MV‘

order by 1, 2;

TABLE_NAME                     COLUMN_NAME                              NUM_DISTINCT
HISTOGRAM

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

MRKTNG_CHNNL_ORDR_EXTN_MV      ORDER_NO                                     41692847
HEIGHT BALANCED

SELECT dbms_metadata.get_ddl(‘TABLE‘,
‘MRKTNG_CHNNL_ORDR_EXTN_MV‘,‘NTCOM‘) FROM DUAL;可以看到物化视图的定义

可以让这个物化视图走下索引看看效率，要是效率不行的话，那就只能全表扫描了。当然可以专门为这个物化视图加个parallel hint从而全表扫的时候更快。

走索引并没有做测试

后面测了其中一个select的执行时间，大约30S左右，提升了很多。估计整个union做完就1-3mins。比之前的45mins快多了。

以上三点就是看了这个sql的执行计划得出来的结论，总结如下：

1.索引没走因为谓词的条件写的不规范

2.select join与union的逻辑，稍微重写下在逻辑不变的情况下可以减少一次物化视图全表扫描

3.物化视图也可以走索引，从而看看有没有加快查询的可能性，这里走了全表扫描。

=======================================ENDED================

时间： 2024-10-13 13:01:43

关于一个sql的优化分析的相关文章

SQL性能优化案例分析

这段时间做一个SQL性能优化的案例分析, 整理了一下过往的案例,发现一个比较有意思的,拿出来给大家分享. 这个项目是我在项目开展2期的时候才加入的, 之前一期是个金融内部信息门户, 里面有个功能是收集各个上市公司的财报, 然后做各种分析, 数据图表展示, 使用的人数并不多, 仅百人左右. 2期打算面向行外用户, 刚开始预计同时在线人数不超过50, 就以50访问用户/秒的性能测试, 结果在把1期的图表类数据展示响应基本在5分钟左右, 属于严重不可用, 说说我们的服务器配置, 有2台网站前端承载用户

[转]一个用户SQL慢查询分析，原因及优化

来源:http://blog.rds.aliyun.com/2014/05/23/%E4%B8%80%E4%B8%AA%E7%94%A8%E6%88%B7sql%E6%85%A2%E6%9F%A5%E8%AF%A2%E5%88%86%E6%9E%90%EF%BC%8C%E5%8E%9F%E5%9B%A0%E5%8F%8A%E4%BC%98%E5%8C%96/ 问题描述 一个用户反映先线一个SQL语句执行时间慢得无法接受.SQL语句看上去很简单(本文描述中修改了表名和字段名):SELECT cou

sql语句的优化分析

摘自  http://www.cnblogs.com/knowledgesea/p/3686105.html sql语句性能达不到你的要求,执行效率让你忍无可忍,一般会时下面几种情况. 网速不给力,不稳定. 服务器内存不够,或者SQL 被分配的内存不够. sql语句设计不合理 没有相应的索引,索引不合理 没有有效的索引视图 表数据过大没有有效的分区设计 数据库设计太2,存在大量的数据冗余 索引列上缺少相应的统计信息,或者统计信息过期 .... 那么我们如何给找出来导致性能慢的的原因呢? 首先你要

SQL语句优化技术分析

摘自  http://www.cnblogs.com/wxj1020/archive/2008/04/27/1173638.html 最近几周一直在进行数据库培训,老师精湛的技术和生动的讲解使我受益匪浅.为了让更多的新手受益,我抽空把SQL语句优化部分进行了整理,希望大家一起进步. 一.操作符优化 1.IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格.但是用IN的SQL性能总是比较低的,从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以

【转】sql语句的优化分析

开门见山,问题所在 sql语句性能达不到你的要求,执行效率让你忍无可忍,一般会时下面几种情况. 网速不给力,不稳定. 服务器内存不够,或者SQL 被分配的内存不够. sql语句设计不合理 没有相应的索引,索引不合理 没有有效的索引视图 表数据过大没有有效的分区设计 数据库设计太2,存在大量的数据冗余 索引列上缺少相应的统计信息,或者统计信息过期 .... 那么我们如何给找出来导致性能慢的的原因呢? 首先你要知道是否跟sql语句有关,确保不是机器开不开机,服务器硬件配置太差,没网你说p啊 接着你使

分析oracle的执行计划（explain plan）并对对sql进行优化实践

基于oracle的应用系统很多性能问题,是由应用系统sql性能低劣引起的,所以,sql的性能优化很重要,分析与优化sql的性能我们一般通过查看该sql的执行计划,本文就如何看懂执行计划,以及如何通过分析执行计划对sql进行优化做相应说明. 一.什么是执行计划(explain plan) 执行计划:一条查询语句在oracle中的执行过程或访问路径的描述. 二.如何查看执行计划 1.set autotrace on 2.explain plan for sql语句; select plan_tabl

戈多编程-小谈sql语句的优化分析

在sqlserver大数据查询中,避免不了查询效率减慢,暂且抛弃硬件原因和版本原因,仅从sql语句角度分析. 一. sql 语句性能不达标,主要原因有一下几点: 1. 未建索引,检索导致全表扫描 2. 已建索引,但是未走索引导致索引失效,进而全表扫描. 3. 没有有效的索引视图 二. sql 语句优化 1. 分析比较执行时间计划读取情况 (1) 查看执行时间和cpu占用时间和查询对I/O的操作情况 I.先执行一个400多万数据的sql set statistics time,io on sele

[转]SQL语句优化技术分析

一.操作符优化 1.IN 操作符 用IN写出来的SQL的优点是比较容易写及清晰易懂,这比较适合现代软件开发的风格.但是用IN的SQL性能总是比较低的,从Oracle执行的步骤来分析用IN的SQL与不用IN的SQL有以下区别: ORACLE试图将其转换成多个表的连接,如果转换不成功则先执行IN里面的子查询,再查询外层的表记录,如果转换成功则直接采用多个表的连接方式查询.由此可见用IN的SQL至少多了一个转换的过程.一般的SQL都可以转换成功,但对于含有分组统计等方面的SQL就不能转换了. 推荐方案

Oracle数据库该如何着手优化一个SQL

这是个终极问题,因为优化本身的复杂性实在是难以总结的,很多时候优化的方法并不是用到了什么高深莫测的技术,而只是一个思想意识层面的差异,而这些都很可能连带导致性能表现上的巨大差异.所以有时候我们应该先搞清楚需求到底是什么,SQL本身是否合理,这些思考很可能会使优化工作事半功倍.而本文是假设SQL本身合理,从Oracle提供给我们的一些技术手段来简单介绍下Oracle数据库,该如何使用一些现有的技术来优化一个SQL执行的性能. 确定需要优化的SQL文本及当前SQL执行计划 确定SQL涉及的所有表及其