问题原因：

巡检中发现A站点数据库每天上午负载异常增加，通过top查看右上角的负载情况发现1分钟、5分钟、15分钟三个值都高于平时值约为30左右，平时上午巡检时最高为9，从DEM的服务器监控中也发现了负载近日从凌晨3点后负载一直处于过高状态
top状态图（正常）：

top状态图（异常）：

top –Hp dmserver_pid（异常）状态图：

DEM主机负载异常状态图：

排查思路：

当数据库出现负载异常时先定位出异常持续的时间，首先排查是否为定时任务或者备份异常引起，然后从sql优化的角度出发。
1.由于数据库每天凌晨三点在A站点进行备份，查看日志中的日常备份和数据库定时任务是否正常执行以及执行备份的结束时间排除备份原因导致。
2.负载过高从sql优化角度排查
（1）、抓到active会话里怀疑对某张400W数据年表的select和update操作造成的，通过使用top -Hp dmserver的pid定位到了大量运行所占cpu为百分之99.99的线程，如上图。
（2）、使用sql定位出线程的trx_id的session情况确定疑问，通过commit日志查看该用户update和select语句执行时长分别约2秒左右，使用manager赋值执行为1毫秒，该表有一个以sql中where条件建立的联合主键索引，查看manager的执行计划正常调用了主键索引，开启commit日志的记录参数信息和数据类型参数，过滤出这两条sql后查看应用端绑定的变量类型，发现where条件中的时间字段应用使用的是timestamp类型进行绑定，表结构中该时间字段为date类型，怀疑数据类型不匹配导致
（3）、使用sql定位出cache_item打印出这两条sql的内存执行计划，发现和manager中计划不一致，在内存的dump中显示为先进行索引扫描后进行过滤
（4）、在manager中以该条select语句为例，不赋值，将时间字段改为timestammp(?)强制执行走timestampl类型查看执行计划发现和dump的相同，确认为时间字段不匹配导致，厂家停止该服务后负载恢复正常，让厂家联系研发修改程序。