【背景】
2019年11月7日周四发版结束前,应用反馈说有一条sql语句执行时间变长,原来整个功能需要8秒左右,现在大概需要20秒钟,他们锁定一个模块的sql语句,发现这条sql执行时间在10秒左右,现在需要分析SQL问题所在。
【正文】
沟通发现存在一个现象,查询10月到11月的数据正常,查询11月到12月就会变慢,从10月到12月也不存在问题,10月到11月数据量是2805条,11月,二线提醒有可能存在因统计信息导致的谓词越界。
以下是执行计划:
实际执行时间为24.29秒,其中在第4步的嵌套循环耗费24.18秒,第23步耗费23.71秒;查询统计信息发现最近一次收集在10月29日,统计行数为585690条,实际count发现是605649条,统计信息基本准确。
查看E-Rows和对应的A-Rows发现第12步表TABLE_SCHEDULE预估返回8行,实际返回18376行,说明在条件范围内的统计信息存在较大偏差,错误的统计信息导致数据库采用NESTED LOOPS方式的执行计划,第10步的NESTED LOOPS实际要循环18376次;最终由于各层的HASH JOIN结果导致最终需要进行26496次嵌套循环,严重影响查询性能。
现在需要更新表TABLE_SCHEDULE的统计信息
exec dbms_stats.gather_table_stats(ownname => ‘USERNAME’,tabname => ‘TABLE_SCHEDULE’,granularity => ‘ALL’,cascade => true);
收集完成后,再次查看执行计划,已恢复正常:
附:
执行计划获取步骤
Set linesize 500
set termout off
1、alter session set statistics_level = all;
2、执行SQL语句
3、查看执行计划
select * from table(dbms_xplan.display_cursor(null,null,’ADVANCED ALLSTATS LAST PEEKED_BINDS’));
数据库技术:谓词越界分析地址:https://blog.csdn.net/u012232730/article/details/107158270
需要了解更多数据库技术:谓词越界分析,都可以关注数据库技术分享栏目—计算机技术网(www.ctvol.com)!
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/dtteaching/629202.html