项目中经常遇到sql运行效率问题，一般需要查询sql执行计划，了解当前执行计划是否最优。比较常见的统计信息过旧导致sql性能问题，而在DM8中统计信息收集后，仍使用旧的行计划。通过测试复现该问题。

环境准备
1、新建测试表
SQL> select * from v$version;

行号 BANNER

1 DM Database Server 64 V8
2 DB Version: 0x7000c
3 03134283890-20220304-158322-10045：
SQL> create table t as select * from dba_objects;
操作已执行
SQL> select count(*) from t;

行号 COUNT(*)

1 854

已用时间: 144.956(毫秒). 执行号:202.
2、创建索引
create index indt on t(object_id);
查看执行计划
SQL> select count(*) from t where object_id>1;

行号 COUNT(*)

1 852

 在会话1中执行：
SQL> set autotrace trace
SQL> select * from t where object_id>1;
…………………………
1 #NSET2: [1, 42->857, 602]
2 #PRJT2: [1, 42->857, 602]; exp_num(16), is_atom(FALSE)
3 #BLKUP2: [1, 42->857, 602]; INDT(T)
4 #SSEK2: [1, 42->857, 602]; scan_type(ASC), INDT(T)

当前执行计划采用索引扫描，可以看出评估数据与实际数据相差较大。实际上该sql采用全表扫描性能更优。

 在会话2中执行统计信息收集，并执行sql：
SQL> dbms_stats.gather_table_stats(‘SYSDBA’,‘T’);
DMSQL 过程已成功完成
已用时间: 00:00:01.422. 执行号:2600.
SQL> explain select * from t where object_id>1;

1 #NSET2: [1, 857, 602]
2 #PRJT2: [1, 857, 602]; exp_num(16), is_atom(FALSE)
3 #SLCT2: [1, 857, 602]; T.OBJECT_ID > var1
4 #CSCN2: [1, 859, 602]; INDEX33555536(T)
优化器已选择了正确的执行计划。

 在会话1中再此执行查询语句：
1 #NSET2: [1, 42->857, 602]
2 #PRJT2: [1, 42->857, 602]; exp_num(16), is_atom(FALSE)
3 #BLKUP2: [1, 42->857, 602]; INDT(T)
4 #SSEK2: [1, 42->857, 602]; scan_type(ASC), INDT(T)

执行计划却没有变化。

在会话2中，清理缓存的执行计划：
SQL> SP_CLEAR_PLAN_CACHE(); ------也可以指定某一条
DMSQL 过程已成功完成
已用时间: 42.985(毫秒). 执行号:2601.

然后，继续在会话1执行sql，并查看执行计划：
1 #NSET2: [1, 857->857, 602]
2 #PRJT2: [1, 857->857, 602]; exp_num(16), is_atom(FALSE)
3 #SLCT2: [1, 857->857, 602];
4 #CSCN2: [1, 859->859, 602]; INDEX33555536(T)

此时，优化器选择了正确的执行计划。

总结
sql缓存中存在已有sql的执行计划时，一般会重用，当不存在时，才会执行硬解析，重新生成执行计划，因此有可能在高并发、较繁忙的系统上，即时收集了统计信息，执行计划也不会改变。
解决方式：
•通过SP_CLEAR_PLAN_CACHE清理某条或全部sql缓存计划
•在表上执行DDL操作
•如果查询对象是其他用户对象，可通过revoke收回权限，然后重新赋权

注意：
目前存储过程dbms_stats.gather_table_stats的参数no_invalidate（是否让依赖游标失效），为保留参数，暂不起作用。

达梦技术社区：https://eco.dameng.com
24小时免费服务热线：400 991 6599