典型案例1:
修改为如下sql:
上面的典型案例中,在列a.END_DATE上进行了计算a.END_DATE - sysdate,导致列a.END_DATE上的索引失效,修改前执行时间422ms,修改后执行时间16ms;索引失效的原因是索引是针对原值建的二叉树,将列值计算后,原来的二叉树就用不上了;为了解决索引列上计算引起的索引失效问题,将计算放到索引列外的表达式上。
典型案例2:
修改为如下sql:
上面的案例中,在列a.HANDLE_TIME进行了to_char(a.HANDLE_TIME, 'yyyyMMdd')计算,导致列a.HANDLE_TIME上的索引失效;修改前执行时间78ms,修改后执行时间31ms。
- select *
- from arc_s_app a
- where a.APP_TYPE_CODE = '203'
- and a.ORG_NO like '23404%'
- and (a.END_DATE - sysdate) < 7
- and (a.END_DATE - sysdate) >= 0
修改为如下sql:
- select *
- from arc_s_app a
- where a.APP_TYPE_CODE = '203'
- and a.ORG_NO like '23404%'
- and a.END_DATE < sysdate + 7
- and a.END_DATE >= sysdate
上面的典型案例中,在列a.END_DATE上进行了计算a.END_DATE - sysdate,导致列a.END_DATE上的索引失效,修改前执行时间422ms,修改后执行时间16ms;索引失效的原因是索引是针对原值建的二叉树,将列值计算后,原来的二叉树就用不上了;为了解决索引列上计算引起的索引失效问题,将计算放到索引列外的表达式上。
典型案例2:
- select *
- from s_app a, c_cons b, sa_c_trade_type c
- where a.CONS_NO = b.CONS_NO
- and c.TRADE_CODE = a.TRADE_CODE
- and to_char(a.HANDLE_TIME, 'yyyyMMdd') >= '20080901'
- and to_char(a.HANDLE_TIME, 'yyyyMMdd') < '20080902'
- and a.ORG_NO in (select ORG_NO from sa_org where ORG_TREE like '23101%')
修改为如下sql:
- select *
- from s_app a, c_cons b, sa_c_trade_type c
- where a.CONS_NO = b.CONS_NO
- and c.TRADE_CODE = a.TRADE_CODE
- and a.HANDLE_TIME >= to_date('20080901', 'yyyyMMdd')
- and a.HANDLE_TIME < to_date('20080902', 'yyyyMMdd')
- and a.ORG_NO in (select ORG_NO from sa_org where ORG_TREE like '23101%')
上面的案例中,在列a.HANDLE_TIME进行了to_char(a.HANDLE_TIME, 'yyyyMMdd')计算,导致列a.HANDLE_TIME上的索引失效;修改前执行时间78ms,修改后执行时间31ms。