有没有人遇到以下问题，并find了解决办法：
我们网站后端的很大一部分是MS SQL Server 2005.每周或两周，网站开始运行速度较慢 – 而且我发现在SQL中查询花费的时间越来越长。 我有一个我喜欢使用的查询：
USE master select text,wait_time,blocking_session_id AS "Block", percent_complete, * from sys.dm_exec_requests CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2 order by start_time asc 这是相当有用的…它提供了在这个时候对你的SQL服务器运行正确的一切的快照。 有什么好处的是，即使你的CPU因为某种原因被挂在100％，活动监视器拒绝加载（我敢肯定你们中的一些人已经在那里），这个查询仍然会返回，你可以看到什么查询正在杀死你的数据库。
当我运行这个或活动监视器在SQL开始放缓的时候，我没有看到任何具体的查询导致这个问题 – 他们都在全线运行速度慢。 如果我重新启动MS SQL服务，那么一切都很好，它加快了速度 – 一两个星期，直到它再次发生。
没有什么我能想到的，但是这只是几个月前才开始的…想法？
– 添加
请注意，当数据库减速发生时，如果我们每小时（每天繁忙的时间）获得100K页面浏览量，或者每小时（慢时间）10K页面浏览量，那么查询所需的时间比正常时间更长，这并不重要。 服务器并没有真正承受压力–CPU不高，磁盘使用似乎没有失控…感觉像索引碎片或类似的东西，但似乎并不是案件。
就粘贴上面查询的结果而言，我真的不能这么做。 上面的查询列出了执行任务的用户的login名，整个查询等等。我真的不喜欢在网上发布我的数据库，表格，列和login名：）…我可以告诉你当时正在运行的查询是正常的，我们网站的标准查询一直在运行，没有任何规范。
– 3月24日
自从上次重新启动以来已经过了大概两周了。 我做了一些改变：我发现了一些查询，在这些查询中我们大量使用了完全没有必要的临时表，并让我们的开发人员改变了他们的做法。 我将一些不断（缓慢但确定地）增长的数据库的大小调整为一个智能的增长数据库。 我调整了一切的自动增长设置，以更聪明（他们都被设置为1MB增长）。 最后我清理了一下MSDB。 我们做日志传送，并且确实不需要保存好几年和几年的备份点，我写了一些脚本，只保留了几个月。 我会不断更新这个线程，因为现在还不知道问题是否已经解决了。
我们find了。 事实certificate，它实际上是一个Web服务器，它的一个应用程序池有问题。 它会卡住一遍又一遍地运行相同的查询（发生在临时表中）。 它会循环，最终导致SQL服务器的悲伤。 一旦发现这个违规的机器/应用程序池，并“放下”，一切都解决了。
你必须问自己，SQL服务重启会发生什么？ 很多东西，但有两个相关的点出现在脑海里：
1）SQL内存被释放。
它可能 （不知道有多大可能），如果您的MaxMemory设置设置得太高，SQL服务增长使用所有可用的内存，并且Windows开始将重要的东西交换到交换文件。 检查以确保MaxMemory设置为合理的值，留下足够的额外内存用于在该框上运行的任何其他内容（是专用SQL服务器还是应用程序服务器？）
2）TempDB是从默认大小重build。
检查您的默认tempdb文件大小，特别是TempDB日志文件的默认大小和增长间隔。 如果增长间隔设置得太低，那么日志可能会产生一些令人难以置信的内部碎片，这可能会显着减慢正常使用。 请看Kimberly Tripp的这 两篇优秀的博客文章。
你是否大量使用临时表或游标？ 检查任何游标正在closures和正确释放。 还要注意链接的服务器 – 我们必须为旧的链接的Informix服务器使用错误的驱动程序，并且定期地意味着我们必须重新启动服务器。
如果它看起来很奇怪，那么寻找奇怪的。
如果调整SQL服务器设置不帮助尝试Windows任务pipe理器：去进程选项卡，然后选项>列>添加CPU时间，句柄，读取，写入，其他和内存选项。
回到进程列表。 对于每列按高到低sorting，并查看前5个进程。 什么与众不同？ 例如，一个进程的内存泄漏将有一个奇怪的句柄数量。 我们有一些* ki打印机，每2秒为DCSLoader进程添加一个句柄。 几个星期后，一台机器列出了大量的可用内存和CPU，但有一个100,000个句柄的过程，几乎不会移动鼠标指针。
检查你的计划任务清单。 告诉你的AV不要扫描.mdf文件。
戴夫，
你有没有检查等待统计？ 您上面的查询列出了“last_wait_type”列。 该列可能有一些关于查询等待的细节（networking，CPU等）
如果您的备份“恢复模式”是FULL，那么是否备份数据库，然后备份事务日志会改善？ 在磁盘空间不足的系统上，这种事情可能会解释问题。
我似乎有一个非常类似于您的configuration（16Gb，升级到32Gb，MD1000和一个TB磁盘，双quadcore至强）。
唯一帮助我诊断过去奇怪问题的是Erland Sommarskog的beta_lockinfo。 运行时间比较慢。
另外，在SP2之前的SQL 2005中，我遇到了一些棘手的问题，但是SP3非常稳定。
希望这给了更多有用的信息：
SELECT D.text SQLStatement, A.Session_ID SPID, C.BlkBy, ISNULL(B.status, A.status) Status, A.login_name Login, A.host_name HostName, DB_NAME(B.Database_ID) DBName, B.command, ISNULL(B.cpu_time, A.cpu_time) CPUTime, ISNULL((B.reads + B.writes), (A.reads + A.writes)) DiskIO, A.last_request_start_time LastBatch, A.program_name FROM sys.dm_exec_sessions A LEFT JOIN sys.dm_exec_requests B ON A.session_id = B.session_id LEFT JOIN ( SELECT A.request_session_id SPID, B.blocking_session_id BlkBy FROM sys.dm_tran_locks AS A INNER JOIN sys.dm_os_waiting_tasks AS B ON A.lock_owner_address = B.resource_address ) C ON A.Session_ID = C.SPID OUTER APPLY sys.dm_exec_sql_text(sql_handle) D WHERE DB_NAME(B.Database_ID) = 'YourDBName' -- Comment out line for all db's ORDER BY ISNULL(B.cpu_time, A.cpu_time) + ISNULL((B.reads + B.writes), (A.reads + A.writes)) DESC
确保数据库可以：
DBCC CHECKDB -- Checks the allocation and structural integrity of all the objects in the specified database. DBCC UPDATEUSAGE (bybox) -- Reports and corrects pages and row count inaccuracies in the catalog views
请留意以下几点：
DBCC SQLPERF(LOGSPACE)
如果你看到扩张正在进行，那肯定会放慢速度。 如果你运行这个，你会看到你的日志空间越来越近，并且接近100％，那么日志将会扩展，并且这个百分比会随着空间的缩小而缩小。 希望在备份启动和清除日志之前，您永远不会看到它展开。
大多是白痴的configuration。 发生。
首先，您应该在维护运行中定期运行索引碎片整理。 在进行备份之前或之后，将其作为活动进行安排。
其次，不要自动增长你的数据库，特别是不要自动填充它。 根据负载autogrow / autoshrink基本上是自杀的设置。
没有看到像这样几乎减缓SQL Server。 你可以发布rest压力下的查询结果吗？ 当然，你的一端没有什么重载SQL Server呢？