谓词越界分析

【背景】

         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

THE END
喜欢就支持一下吧
点赞5分享