程序猿是如何解决SQLServer占CPU100%的
文章目录
- 遇到的问题
- 有哪些SQL语句会致使CPU太高?
-
查看SQL的查询计划node
- 其余优化手段
-
总结git
遇到的问题
有同事反应服务器CPU太高,一看截图基本都是100%了,my god,这但是大问题,赶忙先看看。面试
让同事查看系统进程,发现是SQLServer的CPU占用比较高。首先想到的是否是报表生成的时候高,由于这块以前出现过问题,关掉服务程序,仍是高。难道是客户端程序引起的?可是这么多的客户端链接,难不成每一个都叫人关闭,很简单,把网络断开便可。网络断开以后,CPU立马降低。那么问题到底在哪里呢,是时候祭出咱们的利器了——SQLServer Profiler。算法
使用SQLServer Profiler监控数据库
让同事使用SQLProfiler监控了大概20分钟左右,而后保存为跟踪文件*.rtc。sql
咱们来看看究竟是哪句SQL有问题:数据库
SQL1:查找最新的30条告警事件
select top 30 a.orderno,a.AgentBm,a.AlarmTime,a.RemoveTime,c.Name as AddrName,b.Name as MgrObjName,a.Ch,a.Value,a.Content,a.Level ,ag.Name as AgentServerName,a.EventBm,a.MgrObjId,a.Id,a.Cfmoper,a.Cfm,a.Cfmtime,a.State,a.IgnoreStartTime,a.IgnoreEndTime ,a.OpUserId,d.Name as MgrObjTypeName,l.UserName as userName,f.Name as AddrName2 from eventlog as a left join mgrobj as b on a.MgrObjId=b.Id and a.AgentBm=b.AgentBm left join addrnode as c on b.AddrId=c.Id left join mgrobjtype as d on b.MgrObjTypeId=d.Id left join eventdir as e on a.EventBm=e.Bm left join agentserver as ag on a.AgentBm=ag.AgentBm left join loginUser as l on a.cfmoper=l.loginGuid left join addrnode as f on ag.AddrId=f.Id where ((MgrObjId in ( select Id from MgrObj where AddrId in ('','02100000','02113000','02113001','02113002','02113003','02113004' ,'02113005','02113006','02113007','02113008','02113009','02113010','02113011','02113012' ,'02113013','02113014','02113015','02113016','02113017','02113018','02113019','02113020' ,'02113021','02113022','02113023','02113024','02113025','02113026'))) or (mgrobjid in ('00000000-0000-0000-0000-000000000000','00000000-0000-0000-0000-000000000000' ,'00000000-0000-0000-0000-000000000000','11111111-1111-1111-1111-111111111111' ,'11111111-1111-1111-1111-111111111111')) ) order by alarmtime DESC
SQL2:获取当前的总报警记录数
select count(*) from eventlog as a left join mgrobj as b on a.MgrObjId=b.Id and a.AgentBm=b.AgentBm left join addrnode as c on b.AddrId=c.Id left join mgrobjtype as d on b.MgrObjTypeId=d.Id left join eventdir as e on a.EventBm=e.Bm where MgrObjId in ( select Id from MgrObj where AddrId in ('','02100000','02100001','02100002','02100003','02100004','02100005','02100006','02100007' ,'02100008','02100009','02100010','02100011','02100012','02100013','02100014','02100015' ,'02100016','02100017','02100018','02100019','02101000','02101001','02101002','02101003' ,'02101004','02101005','02101006','02101007','02101008','02101009','02101010','02101011','02101012' ,'02101013','02101014','02101015','02101016','02101017','02101018','02101019','02101020','02101021' ,'02101022','02101023','02101024','02101025','022000','022001','022101','022102','0755','0755002') ) and mgrobjid not in ( '00000000-0000-0000-0000-000000000000','00000000-0000-0000-0000-000000000000','00000000-0000-0000-0000-000000000000' ,'11111111-1111-1111-1111-111111111111','11111111-1111-1111-1111-111111111111')
这是典型的获取数据并分页的数据,一条获取最新分页记录总数,一条获取分页记录,正是获取最新事件这里致使的CPU太高。这里的业务大概是每一个客户端,每3秒执行一次数据库查找,以便显示最新的告警事件。好了,元凶找到了,怎么解决?缓存
有哪些SQL语句会致使CPU太高?
上网查看了下文章,得出如下结论:服务器
1.编译和重编译微信
编译是 Sql Server 为指令生成执行计划的过程。Sql Server 要分析指令要作的事情,分析它所要访问的表格结构,也就是生成执行计划的过程。这个过程主要是在作各类计算,因此CPU 使用比较集中的地方。
执行计划生成后会被缓存在 内存中,以便重用。可是不是全部的均可以 被重用。在不少时候,因为数据量发生了变化,或者数据结构发生了变化,一样一句话执行,就要重编译。
2.排序(sort) 和 聚合计算(aggregation)
在查询的时候,常常会作 order by、distinct 这样的操做,也会作 avg、sum、max、min 这样的聚合计算,在数据已经被加载到内存后,就要使用CPU把这些计算作完。因此这些操做的语句CPU 使用量会多一些。
3.表格链接(Join)操做
当语句须要两张表作链接的时候,SQLServer 经常会选择 Nested Loop 或 Hash 算法。算法的完成要运行 CPU,因此 join 有时候也会带来 CPU 使用比较集中的地方。
4.Count(*) 语句执行的过于频繁
特别是对大表 Count() ,由于 Count() 后面若是没有条件,或者条件用不上索引,都会引发 全表扫描的,也会引发 CPU 的大量运算
大体的缘由,咱们都知道了,可是具体到咱们上述的两个SQL,好像都有上述提到的这些问题,那么到底哪一个才是最大的元凶,咱们可以怎么优化?
查看SQL的查询计划
SQLServer的查询计划很清楚的告诉了咱们到底在哪一步消耗了最大的资源。咱们先来看看获取top30的记录:
排序居然占了94%的资源。原来是它!同事立刻想到,用orderno排序会不会快点。先把上述语句在SQLServer中执行一遍,清掉缓存以后,大概是2~3秒,而后排序字段改成orderno,1秒都不到,果真有用。可是orderno的顺序跟alarmTime的顺序是不彻底一致的,orderno的排序没法替代alarmTime排序,那么怎么办?我想,由于选择的是top,那么由于orderno是汇集索引,那么选择前30条记录,能够当即返回,根本无需遍历整个结果,那么若是alarmTime是个索引字段,是否能够加快排序?
选择top记录时,尽可能为order子句的字段创建索引
先创建索引:
IF NOT EXISTS(SELECT * FROM sysindexes WHERE id=OBJECT_ID('eventlog') AND name='IX_eventlog_alarmTime') CREATE NONCLUSTERED INDEX IX_eventlog_alarmTime ON dbo.eventlog(AlarmTime)
在查看执行计划:
看到没有,刚才查询耗时的Sort已经消失不见了,那么怎么验证它可以有效的下降咱们的CPU呢,难道要到现场部署,固然不是。
查看SQL语句CPU高的语句
SELECT TOP 10 TEXT AS 'SQL Statement' ,last_execution_time AS 'Last Execution Time' ,(total_logical_reads + total_physical_reads + total_logical_writes) / execution_count AS [Average IO] ,(total_worker_time / execution_count) / 1000000.0 AS [Average CPU Time (sec)] ,(total_elapsed_time / execution_count) / 1000000.0 AS [Average Elapsed Time (sec)] ,execution_count AS "Execution Count",qs.total_physical_reads,qs.total_logical_writes ,qp.query_plan AS "Query Plan" FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.plan_handle) st CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp ORDER BY total_elapsed_time / execution_count DESC
咱们把建索引先后CPU作个对比:
已经明显减低了。
经过创建相关索引来减小表扫描
咱们再来看看count(*)这句怎么优化,由于上面的这句跟count这句差异就在于order by的排序。老规矩,用查询计划看看。
用语句select count(0) from eventlog
一看,该表已经有20多w的记录,每次查询30条数据,居然要遍历这个20多w的表两次,能不耗CPU吗。咱们看看是否可以利用相关的条件来减小表扫描。很明显,咱们能够为MgrObjId创建索引:
CREATE NONCLUSTERED INDEX IX_eventlog_moid ON dbo.eventlog(MgrObjId)
可是不管我怎么试,都是没有利用到索引,难道IN子句和NOT IN子句是无法利用索引必定会引发表扫描。因而上网查资料,找到桦仔的文章,这里面有解答:
SQLSERVER对筛选条件(search argument/SARG)的写法有必定的建议
对于不使用SARG运算符的表达式,索引是没有用的,SQLSERVER对它们很难使用比较优化的作法。非SARG运算符包括
NOT、<>、NOT EXISTS、NOT IN、NOT LIKE和内部函数,例如:Convert、Upper等
可是这偏偏说明了IN是能够创建索引的啊。百思不得其解,通过一番的咨询以后,获得了解答:
不必定是利用索引就是好的,sqlserver根据你的查询的字段的重复值的占比,决定是表扫描仍是索引扫描
有道理,可是我查看了下,重复值并不高,怎么会有问题呢。
关键是,你select的字段,这个地方使用索引那么性能更差,你select字段 id,addrid,agentbm,mgrobjtypeid,name都不在索引里。
真是一语惊醒梦中人,缺的是包含索引!!!关于包含索引的重要性我在这篇文章《我是如何在SQLServer中处理天天四亿三千万记录的》已经提到过了,没想到在这里又从新栽了个跟头。实践,真的是过重要了!
经过创建包含索引来让SQL语句走索引
好吧,立马创建相关索引:
IF NOT EXISTS(SELECT * FROM sysindexes WHERE id=OBJECT_ID('eventlog') AND name='IX_eventlog_moid') CREATE NONCLUSTERED INDEX IX_eventlog_moid ON dbo.eventlog(MgrObjId) INCLUDE(EventBm,AgentBM)
咱们再来看看查询计划:
看到没有,已经没有eventlog表的表扫描了。咱们再来比较先后的CPU:
很明显,这个count的优化,对查询top的语句依然的生效的。目前为止,这两个查询用上去以后,再也没有CPU太高的现象了。
其余优化手段
- 经过服务端的推送,有事件告警或者解除过来才查询数据库。
- 优化上述查询语句,好比count(*)能够用count(0)替代——参考《SQL开发技巧(二)》
- 优化语句,先查询出全部的MgrObjId,而后在作链接
- 为管理对象、地点表等增长索引
- 添加了索引以后,事件表的插入就会慢,可以再怎么优化呢?能够分区创建索引,天天不忙的时候,把新的记录移入到建好索引的分区
固然,这些优化的手段是后续的事情了,我要作的事情基本完了。
总结
- 服务器CPU太高,首先查看系统进程,肯定引起CPU太高的进程
- 经过SQLServer Profiler可以轻易监控到哪些SQL语句执行时间过长,消耗最多的CPU
- 经过SQL语句是能够查看每条SQL语句消耗的CPU是多少
- 致使CPU高的都是进行大量计算的语句:包括内存排序、表扫描、编译计划等。
- 若是使用Top刷选前面几条语句,则尽可能为Order By子句创建索引,这样能够减小对全部的刷选结果进行排序
- 使用Count查询记录数时,尽可能经过为where字句的相关字段创建索引以减小表扫描。若是多个表进行join操做,则把相关的表链接字段创建在包含索引中
- 经过服务端通知的方式,减小SQL语句的查询
- 经过表分区,尽可能下降由于添加索引而致使表插入较慢的影响
参考文章
- SQLSERVR语句 in和exists哪一个效率高本人测试证实
- Sql Server Cpu 100% 的常见缘由及优化
- SQLSERVER排查CPU占用高的状况
- 人人都是 DBA(XII)查询信息收集脚本汇编
最后,感谢博客园DBA桦仔的热心指点。
若是您以为阅读本文对您有帮助,请点一下“推荐”按钮,您的“推荐”将是我最大的写做动力! 若是您想持续关注个人文章,请扫描二维码,关注马非码的微信公众号,我会将个人文章推送给您,并和您一块儿分享我平常阅读过的优质文章。

本文版权归做者和博客园共有,来源网址:http://www.cnblogs.com/marvin/ 欢迎各位转载,可是未经做者本人赞成,转载文章以后必须在文章页面明显位置给出做者和原文链接,不然保留追究法律责任的权利。