oracle小表走索引为什么慢,走了索引为啥还像蜗牛一样？

最新推荐文章于 2024-02-21 09:30:00 发布

weixin_39752215

最新推荐文章于 2024-02-21 09:30:00 发布

阅读量535

点赞数

文章标签： oracle小表走索引为什么慢

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

现象及解决

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

createtablecsy_zj2_acct_0628_t2tablespaceusersnologgingas

SELECT

A.*,

MONTHS_BETWEEN(TO_DATE('201406',

'yyyymm'),

TO_DATE(SUBSTR(TO_CHAR(A.DATE_OPENED_ACCT,

'yyyymmdd'),

6),

'yyyymm')) ASMOB,

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

FROMPUB_SJCJ.csy_zj2_ACCT_0628_T1 A,

RISKREPT.RKO_AMNA B

WHEREA.PARTY_NO=B.PARTY_NO

ANDLENGTH(B.MOBILE_PHONE) = 11

ANDB.MOBILE_PHONELIKE'1%'

;

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

SELECT* FROMTABLE(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* fromvw_table_lhr vwherev.TABLE_NAME='RKO_AMNA';

select* fromvw_table_lhr vwherev.TABLE_NAME='CSY_ZJ2_ACCT_0628_T1';

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

SELECT*

FROMvw_table_index_lhr v

WHEREv.TABLE_NAME= 'RKO_AMNA';

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

优化后sql如下：

createtablecsy_zj2_acct_0628_t2tablespaceusersnologgingas

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')) ASMOB,

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

FROMPUB_SJCJ.csy_zj2_ACCT_0628_T1 A,

RISKREPT.RKO_AMNA B

WHEREA.PARTY_NO=B.PARTY_NO

ANDLENGTH(B.MOBILE_PHONE) = 11

ANDB.MOBILE_PHONELIKE'1%'

;

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

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

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

SELECTdbms_sqltune.report_sql_monitor(sql_id=> 'cg1vcg59qgbp7',

TYPE=> 'active',

report_level=> 'all'

)

FROMdual;

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

SELECTdbms_sqltune.report_sql_monitor(sql_id=> 'cg1vcg59qgbp7',

TYPE=> 'active',

report_level=> 'all',

base_path=> '')

FROMdual;

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

sql实时监控_lhr.zip

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

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

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

SELECTt.qy,

t.ywb,

t.addressid,

t.assemblename,

t.addressid5_id,

t.meid,

t.me_name,

t.me_code,

t.me_spec_cn

FROMxt_addrescover_lhr t

WHEREt.meid= 426296

ANDt.me_specIN

('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,