一个有关走了索引为啥还是这么慢的例子

现象及解决

最近发现一个同事的一个建表sql跑了一天的时间了还没有跑完的迹象，于是决定对其优化优化，原sql如下：

create table csy_zj2_acct_0628_t2 tablespace users nologging as

SELECT

A.*,

MONTHS_BETWEEN(TO_DATE('201406',

'yyyymm'),

TO_DATE(SUBSTR(TO_CHAR(A.DATE_OPENED_ACCT,

'yyyymmdd'),

6),

'yyyymm')) AS MOB,

B.CHINESE_NAME,

B.GENDER,

B.BIRTHDAY,

B.CERTIFICATION_NO,

B.CUST_TYPE,

B.MOBILE_PHONE,

B.BILLING_ADDR,

B.HOME_ADDR,

B.EMPLOYER,

B.EMPLOYER_ADDR

FROM PUB_SJCJ.csy_zj2_ACCT_0628_T1 A,

RISKREPT.RKO_AMNA B

WHERE A.PARTY_NO = B.PARTY_NO

AND LENGTH(B.MOBILE_PHONE) = 11

AND B.MOBILE_PHONE LIKE '1%'

;

sql看着很简单，从外表上看没有什么问题，老规矩，先看看执行计划再说，找到sqlid，然后在sqlplus中执行

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('ghfrjwd78yf2q',0,'advanced')); 得到内存中的执行计划，如下图：

执行计划很简单，先扫描表RKO_AMNA上的索引IDX_RKO_AMNA_MBP，然后回表读，然后做2次NL连接操作，即执行计划路径为：5->4->6->3->7->2->1->0 ,cost花费也不是很高，但是我们从Predicate Information中看到一个异常的访问路径，就是第5步，按照道理第5步应该走的是filter过滤的，但是现在成了access访问了，凭经验估计是索引走错了，应该走RKO_AMNA上的PARTY_NO列的索引，当然这只是猜测，我们看一下IDX_RKO_AMNA_MBP是属于哪个列上的就真相大白了，好吧，先看看2个表的数据量吧，因为任何离开数据量谈优化都是没有意义的。

select * from vw_table_lhr v where v.TABLE_NAME='RKO_AMNA';

select * from vw_table_lhr v where v.TABLE_NAME='CSY_ZJ2_ACCT_0628_T1';

可以看出2个表都不是分区表，但是数据量稍微大点，一个2000W，一个1000W，分析日期都是最近分析的，但是不至于跑这么慢吧，再看看IDX_RKO_AMNA_MBP是属于哪个列上的索引呢？

SELECT *

FROM vw_table_index_lhr v

WHERE v.TABLE_NAME = 'RKO_AMNA';

可以看出IDX_RKO_AMNA_MBP是属于MOBILE_PHONE列上的索引，至此说明我们之前的猜测是合理的，oracle每次做nl连接都是去访问索引IDX_RKO_AMNA_MBP的，而不是走唯一索引PK_RKO_AMNA的，操蛋呀，有唯一索引不走，走什么普通索引呀，，，，真是的，，，，，问题找见了那就对其优化优化呗，想了想采用hint来影响其执行计划吧，考虑到数据量大，所以不建议做nl连接，那就做hash连接吧，且让小表做驱动表，这里涉及到表之间的连接关系，有关这一方面的内容这里暂且给大家一个图，详细内容以后再写吧。

优化后sql如下：

create table csy_zj2_acct_0628_t2 tablespace users nologging as

SELECT /*+leading(a) index(b,PK_RKO_AMNA)*/

A.*,

MONTHS_BETWEEN(TO_DATE('201406',

'yyyymm'),

TO_DATE(SUBSTR(TO_CHAR(A.DATE_OPENED_ACCT,

'yyyymmdd'),

6),

'yyyymm')) AS MOB,

B.CHINESE_NAME,

B.GENDER,

B.BIRTHDAY,

B.CERTIFICATION_NO,

B.CUST_TYPE,

B.MOBILE_PHONE,

B.BILLING_ADDR,

B.HOME_ADDR,

B.EMPLOYER,

B.EMPLOYER_ADDR

FROM PUB_SJCJ.csy_zj2_ACCT_0628_T1 A,

RISKREPT.RKO_AMNA B

WHERE A.PARTY_NO = B.PARTY_NO

AND LENGTH(B.MOBILE_PHONE) = 11

AND B.MOBILE_PHONE LIKE '1%'

;

对优化后的sql查询到sqlid，取出内存中的执行计（SELECT * FROMTABLE(DBMS_XPLAN.DISPLAY_CURSOR('as4mp6r714m2u',0,'advanced'));）

似乎花费cost比优化之前多了，没关系，在oracle中没有绝对的东东，凭经验这个语句应该可以了，为了不丢人，自己先跑得试试，快的话再发给同事修改吧，跑的过程中顺便截取了一下sql的实时监控信息，除了pga占用的有点高其他还算正常吧。

这里列出sql实时监控的sql，如果可以连接到oracle的官方网站的话，可以这样运行：

SELECT dbms_sqltune.report_sql_monitor(sql_id => 'cg1vcg59qgbp7',

TYPE => 'active',

report_level => 'all'

)

FROM dual;

如果不能连接到官网，那么在本地安装了tomcat后，下载相应的文件之后，就可以在本机这样查看：

SELECT dbms_sqltune.report_sql_monitor(sql_id => 'cg1vcg59qgbp7',

TYPE => 'active',

report_level => 'all',

base_path => 'http://localhost:8080/sqlmon')

FROM dual;

有关sql实时监控的这一部分内容以后给大家写博客补上吧，具体html文件参考附件
sql实时监控_lhr.zip

最后跑完的时候我看了下大约就2个小时30分钟，还可以了，就这样吧。

与此相关还有一个例子，这里列出来供大家参考：

如果一张表上有多个索引且查询条件中多个列都用到了的话，有可能是没有走正确的索引，有的时候创建了组合索引，在用的时候没有走正确的索引，导致很慢。例：

SELECT t.qy,

t.ywb,

t.addressid,

t.assemblename,

t.addressid5_id,

t.meid,

t.me_name,

t.me_code,

t.me_spec_cn

FROM xt_addrescover_lhr t

WHERE t.meid = 426296

AND t.me_spec IN

('com.gxlu.ngrm.equipment.DP',

'com.gxlu.ngrm.equipment.InfoPoint',

'com.gxlu.ngrm.equipment.OBD',

'com.gxlu.ngrm.equipment.OFXHME');

以上查询语句中,xt_addrescover_lhr在meid和me_spec都有索引，如果执行上边的语句可能会走me_spec列上的索引，这个时候导致很慢，几个小时也查询不出来，但是如果走meid的索引就很快了。

SELECT /*+index(t,IDX_ADDRESCOVER_MEID)*/

t.qy,

t.ywb,

t.addressid,

t.assemblename,

t.addressid5_id,

t.meid,

t.me_name,

t.me_code,

t.me_spec_cn

FROM xt_addrescover_lhr t

WHERE t.meid = 426296

AND t.me_spec IN

('com.gxlu.ngrm.equipment.DP',

'com.gxlu.ngrm.equipment.InfoPoint',

'com.gxlu.ngrm.equipment.OBD',

'com.gxlu.ngrm.equipment.OFXHME');

总结

1.本文设计到执行计划的查看、表之间的连接方式（常用3种）、11g新特性的sql的实时监控等方面的知识，由于篇幅原因没有一一列出，如果有需要以后再写写这些方面的东东吧，看网友需要吧

2.Sql优化有很多经典的例子，但是最基本的都是网上列出来的需要注意的一些事项，本文的情况就属于表上多个索引的选择性问题

3. 有关sql优化中索引这一部分是最重要的一部分，大家一定要活学活用

走了索引为啥还像蜗牛一样相关推荐

oracle小表走索引为什么慢,走了索引为啥还像蜗牛一样？
一个有关走了索引为啥还是这么慢的例子现象及解决最近发现一个同事的一个建表sql跑了一天的时间了还没有跑完的迹象,于是决定对其优化优化,原sql如下: createtablecsy_zj2_acct ...
走了索引为啥还像蜗牛一样？
一个有关走了索引为啥还是这么慢的例子现象及解决最近发现一个同事的一个建表sql跑了一天的时间了还没有跑完的迹象,于是决定对其优化优化,原sql如下: create table csy_zj2_ac ...
Sql Server查询性能优化之走出索引的误区
据了解绝大多数开发人员对于索引的理解都是一知半解,局限于大多数日常工作没有机会.也什么没有必要去关心.了解索引,实在哪天某个查询太慢了找到查询条件建个索引就ok,哪天又有个查询慢了,再建立个索引就是, ...
mysql索引为啥要选择B+树 (上)
不知道你有没有这种感觉,那些所谓的数据结构和算法,在日常开发工作中很少用到或者几乎不曾用到,可能只是在每次换工作准备面试的时候才会捡起来学习学习. 那我希望今天这篇文章能让你对数据结构的具体应用能有个 ...
hive导数据到mysql 自增主键出错_老大问我：“建表为啥还设置个自增 id ？用流水号当主键不正好么？”...
前言"又要开始新项目了,一顿操作猛如虎,梳理流程加画图.这不,开始对流程及表结构了.我:吧啦吧啦吧啦 --老大:这个建表为啥还设置个自增 id ?直接用流水号(用户号/产品号)当主键不就行 ...
mysql索引为啥要选择B+树 (下)
有读者在 mysql索引为啥要选择B+树 (上) 上篇文章中留言总结了选择 B+ 树的原因,大体上说对了,今天我们再一起来看看具体的原因. 索引为什么要保存在硬盘中首先要明白几个概念,服务器存储一般 ...
Mysql索引数据结构有多个选择，为什么一定要是B+树呢？_面试 (MySQL 索引为啥要选择 B+ 树)
Mysql索引数据结构下面列举了常见的数据结构二叉树红黑树 Hash表 B-Tree(B树) Select * from t where t.col=5 我们在执行一条查询的Sql语句时候,在数 ...
两个datatable合并主键一样覆盖_MySQL 建表为啥还设置个自增 id ？用流水号当主键不正好么？...
又要开始新项目了,一顿操作猛如虎,梳理流程加画图.这不,开始对流程及表结构了. 我:吧啦吧啦吧啦 -- 老大:这个建表为啥还设置个自增 id ?直接用流水号(用户号/产品号)当主键不就行了? 我:这个 ...
mysql 对索引limit_【业务学习】关于MySQL order by limit 走错索引的探讨
Grape 描述今天在跑脚本的时候发现了几条慢查询,根据之前的经验实属不应该,后来经过查找资料和分析出来结果,在这里简单记录一下. 首先,我的sql是这个样子: select `id` from ` ...

走了索引为啥还像蜗牛一样

一个有关走了索引为啥还是这么慢的例子

总结

1.本文设计到执行计划的查看、表之间的连接方式（常用3种）、11g新特性的sql的实时监控等方面的知识，由于篇幅原因没有一一列出，如果有需要以后再写写这些方面的东东吧，看网友需要吧

2.Sql优化有很多经典的例子，但是最基本的都是网上列出来的需要注意的一些事项，本文的情况就属于表上多个索引的选择性问题

3. 有关sql优化中索引这一部分是最重要的一部分，大家一定要活学活用

走了索引为啥还像蜗牛一样相关推荐

最新文章

热门文章

走了索引为啥还像蜗牛一样

一个有关走了索引为啥还是这么慢的例子

总结

1.本文设计到 执行计划的查看、表之间的连接方式（常用3种）、11g新特性的sql的实时监控等方面的知识，由于篇幅原因没有一一列出，如果有需要以后再写写这些方面的东东吧，看网友需要吧

2.Sql优化有很多经典的例子，但是最基本的都是网上列出来的需要注意的一些事项，本文的情况就属于表上多个索引的选择性问题

3. 有关sql优化中索引这一部分是最重要的一部分，大家一定要活学活用

走了索引为啥还像蜗牛一样相关推荐

最新文章

热门文章

1.本文设计到执行计划的查看、表之间的连接方式（常用3种）、11g新特性的sql的实时监控等方面的知识，由于篇幅原因没有一一列出，如果有需要以后再写写这些方面的东东吧，看网友需要吧