一个客户联系我,他写了一个存储过程,其中有一条insert into select的sql语句运行非常缓慢,平均处理每天的数据量需要4分钟,而如果单独执行此sql语句,其实很快,大概6s左右即可完成,返回的条数也不多,总共500条左右,希望帮忙优化一下.
1.先看一下正常的执行sql效率和执行计划
此sql非常长,有多个union all连接而成,大概sql如下:
...
我们看到这个sql通过时间字段enter_date进行了限制,取一天的数据,而且时间字段上面有索引,所以直接执行的时候肯定是走索引的,下面是截取的某一段的执行计划:
由于时间字段是非前缀,所以走的是index skip scan.
2.再看一下存储过程中的执行计划
执行存储过程,在后台通过sql_id查看此sql的真实执行计划,这里我们发现了问题:
这里的inp_bill_detail是大表,上面有索引但是却没有走,而是进行了全表扫描,此过程中有多个类似的sql,全部都是大表的全表扫描,所以肯定就非常慢了
那么我们这里就找到了问题所在,相同的一段sql,直接执行和放到存储过程中执行,却有不同的执行计划,过程中的执行计划很差,导致的运行缓慢.
那么这一段看似相同的sql为啥执行计划不一样呢?sql有什么不同吗?
其实很容易就可以看到,在plsql中直接执行的时候,没有使用绑定变量,是直接输入的参数值,而在过程中执行的时候是使用的绑定变量.那么我们这里想到很可能是绑定变量的原因导致的.
oracle中绑定变量窥探,由隐藏参数_optim_peek_user_binds设置,默认为true开启,当开启了绑定变量窥探,在使用绑定变量的时候,oracle内部会自动窥探绑定变量的值,从而选择合适的执行计划.
一般在oltp环境基本都关闭此参数,防止因为绑定变量的原因导致的执行计划不稳定,检查当前数据库的设置为false:
但是这里明显应该是要开启绑定变量窥探,对查询数据进行限制,执行计划才对.
3.解决办法
既然此参数为false而且数据库运行正常,如果冒然修改此参数可能会带来不确定因素,影响其它正常运行的sql,因此建议还是在sql级别进行单独调整.
使用hint在sql级别进行调整:
调整后的sql执行计划如下:
最后经过确认,每天处理的数据的时间由原来的4分钟减少到了4秒,效果明显!