程序猿是如何解决SQL Server占CPU100%的

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做个比较：

已经明显减低了。

经由过程建立相干索引来削减表扫描

2.排序(sort) 和聚合计算(aggregation)

用语句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)

我们再来看看萌芽筹划：

5/6 首页上一页 3 4 5 6 下一页尾页

　　推荐阅读

　　PHP单元测试与数据库测试

我总感到 PHP 的开辟者们并没有对 PHP 的质量有所寻求，可能是因为 PHP 的机制问题吧，让大年夜部分的开辟者总认为浏览器拜访就没有问题，所以很多时刻，做 PHP 开辟的，就没有单位测试的>>>详细阅读

本文标题：程序猿是如何解决SQL Server占CPU100%的

地址：http://www.17bianji.com/lsqh/34647.html

1/2 1