今天早上系统维护后，发现一个库的CPU奇怪（正常情况下CPU早10到20之间），现在已经在70到90之间了（当然问题，早就出现了，并不是今天早上的偶然事件，因为这个库没有安装监控，所以............）。

检查阻塞情况，排在前2名的是：

1.CXPACKET

2.SOS_SCHEDULER_YIELD

CXPACKET 出现非常高，90％情况是由于并行查询引起的（如果再结合PAGEIOLATCH_XX waits等待事件，可以推断是有可能是进行大表并行查询，使用了不正确的non-clustered或过时的statistics 引起的，导致错误的查询计划），但是这里没有出现PAGEIOLATCH_XX 。我在这里保守的调整了MAXDOP 参数：

EXEC sys.sp_configure N'show advanced options', N'1' RECONFIGURE WITH OVERRIDE

GO

EXEC sys.sp_configure N'max degree of parallelism', N'1'

GO

RECONFIGURE WITH OVERRIDE

GO

EXEC sys.sp_configure N'show advanced options', N'0' RECONFIGURE WITH OVERRIDE

GO

，

这时CPU并没有明显降低，然后通过以下语句拉出高消耗CPU的SQL语句：

select

highest_cpu_queries.*,q.dbid,

q.objectid, q.number, q.encrypted, q.[text]

from

(select top 50 qs.*

from sys.dm_exec_query_stats qs

order by qs.total_worker_time desc) as highest_cpu_queries

cross apply sys.dm_exec_sql_text(plan_handle) as q

order by highest_cpu_queries.total_worker_time desc

go

一查看，发现是开发人员写的SQL有问题。

这是一个很频繁调用的list存储过程，这个存储过程的SQL里面大量使用了系统函数（当然那个表的数据也有点多），导致CPU消耗很高，SQL部分语句如下：

WHERE ISNOTICED = 0 AND (ISNULL(notices, 0) < 6)

AND(@date BETWEEN DATEADD(s, 6, createtime) AND DATEADD(mi, 15, createtime))

ORDER BY CREATETIME desc

当然还有很多，我就不摘录了。和开发人员一起修改了SQL，问题得到解决。

ITPub博客

SQL函数惹得祸（SQL SERVER数据库）

最新文章