合 Oracle一个走了索引为啥还像蜗牛一样的案例

现象及解决

最近发现一个同事的一个建表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'),

1,

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个表的数据量吧，因为任何离开数据量谈优化都是没有意义的。

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章！

验证码：

请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。