谓词越界分析

【背景】

         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