达梦数据库性能优化一例

最近做一个高并发系统的性能优化，发现一个很有意思的问题，和大家分享一下：现象是系统在高峰期比较卡顿，perf top的图如下：

热点很明显，高频sql的执行计划走了全表扫描，但是分析了一遍SQL日志，发现SQL都走了索引，没有走全表扫描，怎么办呢？

这时可以开启达梦中的10003 事件的trace来找找全表扫描的SQL

--开启全表扫描跟踪

alter session 0 set events '10003 trace name context forever, level 1';

--关闭全表扫描跟踪

alter session 0 set events '10003 trace name context off';

 
--查看trace日志所在的目录

select * from v$dm_ini where para_name = 'TRACE_PATH';

 通过10003事件的trace日志发现了一条SQL,如下：

select * from test where id= ？;

拿到管理工具里面看看执行计划：

 可以走索引啊，为啥trace里面显示这条语句走了全表扫描呢？

 开启达梦数据库的SQL日志分析一下参数看看：

SP_SET_PARA_VALUE(1,'SVR_LOG',1);

发现绑定的参数是一个float类型的，然而这个id列是int类型，真相终于大白了，由于应用

没有按照表定义的类型来绑定对应的参数类型，这里存在隐式的类型转换导致了全表扫描，

构造一个例子看看是不是这样：

declare
i float;
begin
  i=268436869;
 select * from "SYSDBA"."TEST" where id= i;
END

 调试一下，看看执行计划是什么：

 不出所料，存在隐世类型转换，本该走索引的SQL走了全表扫描。

问题的根本原因找到了，接下来就好办了，协调应用开发商修改程序，参数绑定改为int类型即可。

这个问题比较隐蔽，应用开发时最好根据数据库中表定义的实际类型来做绑定，不要让数据库去做这种隐式的类型转换，以免造成性能问题。

更多资讯请上达梦技术社区了解 https://eco.dameng.com