最近做一个高并发系统的性能优化，发现一个很有意思的问题，和大家分享一下：现象是系统在高峰期比较卡顿，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类型即可。