你们中是否有人经历过以下情况并找到了解决方案：
我们网站的大部分后端都是 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 并不高，磁盘使用率似乎没有失控......感觉像是索引碎片或类似的东西，但事实似乎并非如此。
至于粘贴我上面粘贴的查询结果，我真的做不到。上面的查询列出了执行任务的用户的登录信息、整个查询等等。我真的不想在网上公布我的数据库、表、列和登录信息的名称 :)... 我可以告诉你，当时运行的查询是正常的，是我们网站一直在运行的标准查询，没有什么不正常的。
--3月24日
距离上次重启已经过去了大约两周。我做了一些更改：我发现一些查询大量使用了完全不必要的临时表，并让我们的开发人员更改了他们的操作方式。我将一些不断（缓慢但稳步）增长的数据库的大小调整为适合其增长的智能大小。我还调整了所有数据库的自动增长设置，使其更加智能（它们全部设置为 1MB 增长）。最后，我清理了 MSDB。我们进行日志传送，实际上不需要保留多年的备份点，我已经编写了一些脚本，将其保留在几个月内。我会继续更新此帖子，因为现在判断问题是否已解决还为时过早。
答案1
我们找到了。原来是 Web 服务器的一个应用程序池出了问题。它会卡在一遍又一遍地运行同一组查询（碰巧处理临时表）。它会一直循环，最终导致 SQL 服务器崩溃。一旦找到并“关闭”这个有问题的机器/应用程序池，一切都解决了。
答案2
你必须问自己，SQL 服务重启时会发生什么？有很多东西，但我想到了两个相关点：
1）SQL内存被释放。
它是可能的（不确定可能性有多大），如果您的 MaxMemory 设置过高，SQL 服务将增长到使用所有可用内存，并且 Windows 开始将重要内容交换到交换文件。检查以确保 MaxMemory 设置为合理的值，为该框上运行的其他任何内容留出足够的额外内存（它是专用的 SQL 服务器吗？还是也是应用服务器？）
2) TempDB 根据默认大小重建。
检查默认的 tempdb 文件大小，尤其是 TempDB 日志文件的默认大小和增长间隔。如果增长间隔设置得太低，则日志可能会积累一些令人难以置信的内部碎片，这会大大降低正常使用速度。请参阅这些 二金伯利·特里普 (Kimberly Tripp) 的精彩博客文章。
答案3
您是否大量使用临时表或游标？检查所有游标是否已正确关闭和释放。还要注意链接服务器 - 我们必须为旧的链接 Informix 服务器使用有缺陷的驱动程序，这意味着我们必须定期重新启动服务器。
答案4
戴夫，
您检查过等待统计数据了吗？您上面给出的查询列出了“last_wait_type”列。该列可能包含有关查询正在等待的内容（网络、CPU 等）的一些详细信息。