问题描述：
看到有一个语句执行时间很长，拿出来看了看执行计划
如下：
Plan Hash Value : 3431444516
| Id | Operation | Name | Rows | Bytes | Cost | Time |
| 0 | DELETE STATEMENT | | 35771435 | 894285875 | 13427529 | 44:45:31 |
| 1 | DELETE | GJT_BALANCE | | | | |
| 2 | PARTITION RANGE ALL | | 35771435 | 894285875 | 13427529 | 44:45:31 |
| * 3 | TABLE ACCESS FULL | GJT_BALANCE | 35771435 | 894285875 | 13427529 | 44:45:31 |
Predicate Information (identified by operation id):
- 3 - filter(TO_CHAR(INTERNAL_FUNCTION(“CREATE_DATE”),‘yyyymmdd’)=TO_CHAR(SYSDATE@!,‘yyyymmdd’))
语句如下：
DELETE GJT_BALANCE
WHERE TO_CHAR(CREATE_DATE, ‘yyyymmdd’) = TO_CHAR(SYSDATE, ‘yyyymmdd’)
首先思路是：根据执行计划看operation项，发现只有一个表GJT_BALANCE ,where条件是create_date ,又看了表的对应列，有索引，但是在执行计划时，没有走索引而是走的table acces full，然后我就用hit 添加强制走索引，如下：**DELETE GJT_BALANCE
WHERE /+index(IDX_CREATE_DATE)/ TO_CHAR(CREATE_DATE, ‘yyyymmdd’) = TO_CHAR(SYSDATE, ‘yyyymmdd’) 但是执行还是没有变化，还是全表扫，有优化方面的大佬，就针对我描述的能给优化一下吗？
你可以尝试建个TO_CHAR(CREATE_DATE, ‘yyyymmdd’)的函数索引或者改造语句条件，WHERE CREATE_DATE = TO_CHAR(SYSDATE, ‘yyyymmdd’)去匹配create_date的时间格式，这儿不走索引是函数转换的关系。我看你这个表是个分区表，建索引时注意一下索引类型。优化得各方面因素综合考虑，你先先在测试环境或者业务低峰期测试正常再在生产变更。
评论
有用 1
表中有create_date的函数索引，所以我走的第二种方式改造语句条件，WHERE CREATE_DATE = TO_CHAR(SYSDATE, ‘yyyymmdd’)
原：DELETE GJT_BALANCE
WHERE TO_CHAR(CREATE_DATE, ‘yyyymmdd’) = TO_CHAR(SYSDATE, ‘yyyymmdd’)
改造完语句是：
DELETE GJT_BALANCE
WHERE TO_CHAR(CREATE_DATE, ‘yyyymmdd’) = TO_CHAR(SYSDATE, ‘yyyymmdd’)
这样是不是就起到一定效果了，执行的结果是不是跟原来的一样？
评论 有用 0后有改了一下原语句的格式：
原来的：
DELETE GJT_BALANCE
WHERE TO_CHAR(CREATE_DATE, ‘yyyy-mm-dd’) = TO_CHAR(SYSDATE, ‘yyyymmdd’)
表中索引：
后对比所写语句，发现函数索引与创建的时候格式，不一致，导致没有走索引，后来把格式改了一下，效果很明显。
改后：
DELETE GJT_BALANCE
WHERE TO_CHAR(CREATE_DATE, ‘YYYY-MM-DD’) = TO_CHAR(SYSDATE, ‘YYYY-MM-DD’)
执行计划：
对比两种修改，最终引起执行时间长，执行计划不优的原因，还是对函数索引不熟悉，再者就是不细心。
评论 有用 0
墨值悬赏