【背景】
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