有搭档反响效劳器CPU过高，一看截图底子都是100%了，my god，这可是大疑问，赶忙先看看。
让搭档检查体系进程，发现是SQLServer的CPU占用比照高。首要想到的是不是报表生成的时分高，由于这块之前呈现过疑问，关掉效劳程序，仍是高。莫非是客户端程序引发的？可是这么多的客户端衔接，难不成每个都叫人封闭，很简略，把网络断开即可。网络断开今后，CPU立马下降。那么疑问究竟在哪里呢，是时分祭出咱们的利器了——SQLServer Profiler。
让搭档运用SQLProfiler监控了大约20分钟摆布，然后保留为盯梢文件*.rtc。
咱们来看看究竟是哪句SQL有疑问：
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
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秒履行一次数据库查找，以便显现最新的告警工作。好了，首恶找到了，怎样处理？
上彀检查了下文章，得出以下定论：
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，如同都有上述说到的这些疑问，那么究竟哪个才是最大的首恶，咱们能够怎样优化？
SQLServer的查询方案很明白的告诉了咱们究竟在哪一步耗费了最大的资本。咱们先来看看获取top30的记载：
排序居然占了94%的资本。本来是它！搭档立刻想到，用orderno排序会不会快点。先把上述句子在SQLServer中履行一遍，清掉缓存今后，大约是2~3秒，然后排序字段改为orderno，1秒都不到，公然有用。可是orderno的次序跟alarmTime的次序是不彻底共同的，orderno的排序无法代替alarmTime排序，那么怎样办？我想，由于挑选的是top，那么由于orderno是集合索引，那么挑选前30条记载，能够当即回来，底子无需遍历悉数成果，那么假设alarmTime是个索引字段，是不是能够加速排序？
先树立索引：
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呢，莫非要到现场布置，当然不是。
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 qsCROSS APPLY sys.dm_exec_sql_text(qs.plan_handle) stCROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qpORDER 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都不在索引里。
真是一语惊醒梦中人，缺的是包括索引！！！
好吧，立马树立有关索引：
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过高的表象了。
当然，这些优化的手法是后续的作业了，我要做的作业底子完了。
