我已经用Profiler审计了SQLS2008服务器了一天..开销似乎没有麻烦这个新客户我的公司。 他们正在使用传统的VB6应用程序作为前端。 一旦SQLS RAM的使用率很高，他们正在经历超时。 服务器当前正在运行x64 sqls2008的虚拟机上有近9 GB的RAM。 SQL Server的“最大服务器内存选项”目前设置为6GB。
我把跟踪的结果放在一个表中，并使用这个查询来查询它们。
SELECT TextData，ApplicationName，Reads
FROM [TraceWednesday] WHERE textdata不为null，EventClass = 12 GROUP BY TextData，ApplicationName，读取ORDER BY读取DESC
正如我所料，一些价值非常高。
Top Reads, in pages. 2504188 1965910 1445636 1252433 1239108 1210153 1088580 1072725 我认为最好的一个（2504188页）是20033504 KB，然后大约是20'000 MB，20GB？ 这些查询经常执行，可能需要一段时间才能运行。 最终RAM因耗尽caching而用尽，一旦SQL无法在缓冲池中“泼溅”页面，就会发生超时。 成本上升。 我的理解是否正确？
我读过我应该调整关联的T-SQL并创build适当的索引。 显然减lessI / O会使SQL Server使用更less的RAM。 或者，也许这可能会减慢咀嚼整个RAM的过程。 如果阅读的页面less得多，即使使用率很高，也可能运行得更好？ （减less时间交换等）
目前，我们唯一的select是在RAM使用率高的时候每周重新启动一次SQL，突然超时消失。 SQL再次呼吸。
我肯定有很多DBA在这种情况下..我在开始挖掘所有糟糕的T-SQL并把索引放在这里和那里之前问，有什么我可以做的吗？ 除了我所知道的任何build议（还没有太多..）
非常感激。
狮子座。
一般来说，SQL Server将分配尽可能多的内存，而不使用分页文件。 该内存被用作数据页面的caching。 （还有一个计划caching和一些其他的东西，但是我认为这个问题已经超出了这个问题的范围）。这个分配的效果是“耗尽”服务器上所有的空闲内存，并且经常担心那些不是熟悉SQL Server。
不要担心内存的大小，不必担心物理页面读取（来自磁盘）和逻辑页面读取（来自内存）。逻辑页面读取不像物理页面读取那样有问题，因为它们发生的更快，但是它们仍然需要一定的时间，即使你有一个TB的TB，并且你的整个数据库被caching在内存中，处理器仍然需要一定的时间来search你的所有数据。如果SQL Server有更less的数据要查看，即使它完全caching在RAM中，也会更好。
如果数据不适合内存，并且服务器必须从磁盘读取数据，则访问数据速度会变慢。
在你的情况下，这听起来像SQL正在读取20 GB的数据。 这将不适合6 GB的数据caching，所以SQL Server将通过从磁盘加载数据来重新使用内存，而不是以前认为不再需要的“旧”数据。 如果来自另一个用户的另一个查询在1秒钟后出现，则SQL可能必须返回到磁盘以重新读取“旧”数据。
调整查询和改进索引应该会导致SQL Server有较less的数据需要查看，这意味着必须查看的数据更可能保留在数据高速caching中，RAM中，并且更less的数据将不得不从磁盘在所需数据不在数据caching中的情况下。
增加内存（“在问题上抛硬件”）也意味着更好的机会将这些数据保存在RAM中，但是通常可以获得更大的改善（如果运气好的话可能是10倍或更多）索引是非常糟糕的开始 – 我已经看到改善60倍和更好）比你可以通过增加可用于caching数据的RAM量（通常不可能增加超过2倍或3倍的RAM的数量没有新的服务器，或者在你的虚拟机环境中施加很多压力。）当然，插入新的RAM芯片通常比调整查询更容易/更快，但是有时你没有任何select。
另一件值得做的事情是确保您的索引统计信息定期更新。 在没有DBA的环境中，这种维护经常被忽略。 过时的统计信息可能会导致查询引擎使用低效的计划，而这对于大型表尤其明显/痛苦。
最后一个观察：重新启动SQL Server将刷新所有的caching数据，并且该数据将不得不重新加载SQL Server重新启动后查询进来的磁盘。 通常，这意味着SQL Server在重新启动后更为缓慢，而不是更快。 重新启动后速度更快的SQL Server通常会遇到过多的阻塞（重新启动服务器会丢弃所有阻塞和阻塞的连接），或者他们已经看到了一堆导致从磁盘读取大量数据的查询（通常情况下，这些查询是由重复提交相同查询几次，几秒钟或几分钟的困扰用户引起的，因为事情“花费太长时间”）。