如何提高 MS SQL Server 中原始查询的性能？

Question

我有一个 ASP.NET 网站，它自己独立缓存数据，并且数据在很长一段时间内不会改变，所以它不需要用相同的查询第二次查询 SQL Server。我需要提高到该 SQL Server 的首次（原始）查询的性能。某些查询处理的数据过多，可能会导致 SQL Server 使用tempdb. 我不使用临时表变量或临时表，因此 SQL Server 决定tempdb在需要时自行使用。

我的数据库大小是 16Gb，我的服务器机器上有 32Gb 的物理 RAM。

我知道 MS SQL Server 缓存策略会尝试将数据保留在 RAM 中，以在类似查询需要再次加载相同数据时提高它们的性能。除此之外，它会尝试使用可用 RAM 而不是 tempdb 来提高性能，而不会导致磁盘访问。

我想当需要在 tempdb SQL Server 中存储某些内容的查询出现并且没有足够的可用 RAM 时，SQL Server 有两种选择：

1) 卸载一些缓存数据并使用备用 RAM 而不是 tempdb 以避免磁盘写入

2) 为将来的查询保留缓存数据并开始使用 tempdb，这会导致写入磁盘速度变慢。

我不知道 SQL Server 在这种情况下会做出什么选择，但我希望它做出选择 #1，因为我只关心首次（原始）查询的性能，因为我再也不会向 SQL Server 发送相同的查询（虽然我可能会发送类似的查询）。

这种情况下的 SQL Server 缓存策略是什么？

它如何在避免原始查询的 tempdb 和第二次查询的速度之间平衡 RAM 的使用？

是否可以将 SQL Server 配置为做出选择 #1 的方式？如果是，那么如何？

我还能如何提高所有原始 SQL 查询的性能？

由于我不知道 SQL Server 缓存策略，我想将数据库放在 RAM 磁盘上。这将确保任何原始查询都具有高速加载未缓存数据的能力，即使 SQL Server 总是做出选择 #1。这样做的风险是，如果 SQL Server 继续选择 #2，它可能会开始使用更多的 tempdb 和更少的可用 RAM（在我使用 16Gb 作为 RAM 磁盘后只剩下 16Gb），这将减慢导致溢出到tempdb.

我对 SQL 2008 R2 的解决方案感兴趣，但我想它可能与 SQL 2008、SQL 2005 和 SQL 2000 相同。

说明：

该机器上没有运行其他应用程序，它专用于 SQL Server。网站在单独的盒子上运行。

它是 Windows Server 2008 R2 Enterprise 64 位上的 SQL Server 2008 R2 标准版 64 位。

我只运行 read-only 查询，并且 database 设置为read-only。

让我们假设已经有好的索引。这个问题是关于 SQL Server 做出选择 #1 与选择 #2，它是如何做到的，是否有办法控制它，以及 RAM 磁盘是否帮助它为原始查询做出正确的选择。

Answer 1

您的问题基本上可以改写为“查询内存授权如何工作？”。关于这个主题的一个很好的读物是理解 SQL 服务器内存授权。在查询开始执行之前，它可能需要为排序和散列以及其他内存饥饿操作授予内存。此内存授予是估计值。根据当前系统状态（正在运行和挂起的请求数、可用内存等），系统向查询授予最多所需数量的内存。一旦获得内存，查询就会开始执行（它可能必须在可怕的“资源信号量”队列中等待才能获得授权）。在执行时保证内存授予由系统。这个内存量可以与数据页共享（因为它们总是可以刷新到磁盘）但永远不会与其他内存使用（即它不能被“窃取”）。因此，当查询开始从其授权中请求提交的内存时，引擎将部署您所谓的“策略 #1”：数据页可能会被逐出（如果脏则刷新），以便为查询提供承诺的内存。现在，如果估计是正确的并且授予是请求内存的 100%，则查询不应“溢出”。但是如果估计不正确（归结为基数估计，因此受制于陈旧的统计数据）或者如果查询没有得到它要求的全部授权，查询将“溢出”。这是 tempdb 出现的时候，性能通常很差。

您可以使用的唯一控制此过程中某些内容的旋钮是Resource Governor。由于 RG 可用于为池指定MIN设置，因此可用于为特定工作负载保留内存，以便它实际获得其请求的内存授予。当然，在您进行适当的调查表明减少内存授予是罪魁祸首之后，当然在评估了对其他工作负载的影响之后。当然，并进行了测试。

现在让我们回到你最初的问题。如果你的调查是正确的（一个很大的如果），我想指出两个问题：

• 您在需要为网站授予内存的生产查询中运行。这是一个很大的禁忌。内存授权表示分析查询在服务 HTTP 请求中没有位置。
• 您的查询可能不是获得他们请求的内存授权的事件。同样，对于像网站这样的延迟关键工作负载来说，更是一个禁忌。

所以这告诉我你有一个基本的设计和架构问题。网站是延迟驱动的，应该创建类似于 OLTP 的工作负载，没有内存授予，查询也没有内存压力。更不用说没有溢出。分析查询应该在离线作业中运行，并存储预处理的结果，以便在 HTTP 请求需要它们时快速可用。