sql 缓冲池

SQL Server retrieves data from two areas; memory and disk. As disk operations are more expensive in terms of IO which means they are much slower SQL stores and retrieves data pages from an area known as the Buffer Pool where operations are much faster.

SQL Server从两个区域检索数据。 内存和磁盘。 由于磁盘操作在IO方面更昂贵，这意味着它们在SQL存储和从称为“缓冲池”的区域中检索数据页的速度要慢得多，在该区域中，操作要快得多。

In order to understand how the Buffer Pool works and how it benefits our query processing we need to see it in action. Fortunately SQL Server gives us several management views and built in functionality to see exactly how the Buffer Pool is being used and how, or more importantly if, our queries are utilising it efficiently.

为了了解缓冲池如何工作以及如何使我们的查询处理受益，我们需要对其进行实际操作。 幸运的是，SQL Server为我们提供了多个管理视图和内置功能，以准确地查看缓冲池的使用方式以及更重要的是，如果查询有效地利用了缓冲池。

Firstly, we need to ensure we have a cold cache to work with; that is a Buffer Pool that is not populated with any pages. We can do this without restarting SQL Server by issuing a DBCC, or Database Console Command entitled DROPCLEANBUFFERS. Prior to doing this we need to issue a CHECKPOINT command, this ensures that any dirty pages are wrote to disk cleaning the buffers, for reference a buffer is a 8 kilobyte page residing in memory.

首先，我们需要确保可以使用冷缓存； 那是一个没有任何页面填充的缓冲池。 我们可以通过发出DBCC或名为DROPCLEANBUFFERS的数据库控制台命令来重新启动SQL Server，而无需重新启动SQL Server。 在执行此操作之前，我们需要发出CHECKPOINT命令，以确保将所有脏页写入磁盘以清理缓冲区，作为参考，缓冲区是驻留在内存中的8 KB页面。

CHECKPOINT -- writes dirty pages to disk, cleans the buffers
DBCC DROPCLEANBUFFERS -- removes all buffers

The following message is displayed:

显示以下消息：

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

DBCC执行完成。 如果DBCC打印了错误消息，请与系统管理员联系。

As I covered in a previous post Monitoring Memory Clerk and Buffer Pool Allocations in SQL Server we can see how the Buffer Pool is allocated by using the sys.dm_os_memory_clerks Dynamic Management View:

正如我在上一篇文章“ 监视SQL Server中的内存文员和缓冲池分配”中所介绍的那样，我们可以看到如何使用sys.dm_os_memory_clerks动态管理视图来分配缓冲池：

--check MEMORYCLERK_SQLBUFFERPOOL allocation
SELECT TOP 10 [type], SUM(pages_kb) / 1024 AS SizeMb
FROM sys.dm_os_memory_clerks
GROUP BY [type]
ORDER BY SUM(pages_kb) / 1024 DESC

If we run this as soon as our Buffer Pool has been flushed we will see the results of our query that similar to the image below:

如果我们在刷新缓冲池后立即运行此命令，我们将看到与下图类似的查询结果：

Here we can see some of SQL Servers current memory allocations and it’s important to understand that although we have flushed the Buffer Pool there are still other things using memory like the SQLOSNODE, CLR and storage engine clerks amongst others, in fact the Buffer Pool itself isn’t at zero but actually has a 1Mb allocation.

在这里，我们可以看到一些SQL Server当前的内存分配，并且很重要的一点是，尽管我们已经刷新了缓冲池，但是还有其他一些使用内存的事物，例如SQLOSNODE，CLR和存储引擎职员，实际上缓冲池本身并不是不是零，但实际上分配了1Mb。

This is important to know because in some way it relates to our Maximum server memory setting in SQL Server (as show below).

这一点很重要，因为它在某种程度上与我们在SQL Server中的“最大服务器内存”设置有关（如下所示）。

This is a screenshot from the server properties of my test instance. This setting isn’t actually the total memory that SQL is allocated, it’s just for the Buffer Pool allocation. This is why you might see SQL Servers memory usage in the likes of Windows Task Manager going above this specified limit from time to time.

这是我的测试实例的服务器属性的屏幕截图。 此设置实际上不是分配给SQL的总内存，仅用于缓冲池分配。 这就是为什么您可能会不时看到Windows Task Manager之类SQL Server内存使用率超过此指定限制的原因。

To see the Buffer Pool in action we need to run some queries and its best to use a table with a relatively high row count; I’m going to use a TOP command to return 10000 rows from one of my test tables. I am also going to use the SET STATISTICS IO ON command so I can see how SQL Server is retrieving the rows.

要查看缓冲池的运行情况，我们需要运行一些查询，最好使用行数相对较高的表。 我将使用TOP命令从我的测试表之一返回10000行。 我还将使用SET STATISTICS IO ON命令，以便了解SQL Server如何检索行。

SET STATISTICS IO ON
SELECT TOP 10000 * FROM Transactions

By clicking the Messages tab we can see how SQL has ‘read’ the data.

通过单击“消息”选项卡，我们可以看到SQL如何“读取”数据。

In this case there are 61 logical reads and 1 physical read. The logical reads are those taken from cache and the physical read is from disk. As memory is much, much faster than disk then the more logical reads the better.

在这种情况下，有61个逻辑读取和1个物理读取。 逻辑读取是从缓存中读取的，而物理读取是从磁盘中读取的。 由于内存比磁盘快得多，因此逻辑读取越多越好。

The read-ahead reads are due to an optimisation within SQL Server that pre-fetches pages from disk into cache. Now if we view the memory clerk allocations again we should see a difference in the Buffer Pool allocation.

预读读取是由于SQL Server中的一项优化，该优化将页面从磁盘预取到缓存中。 现在，如果我们再次查看内存职员分配，我们应该会看到缓冲池分配中的差异。

Now we can see that the MEMORYCLERK_SQLBUFFERPOOL allocation is at 33Mb and to show how this benefits our queries we’ll leave the SET STATISTICS option on and run the query once again and examine the reads:

现在我们可以看到MEMORYCLERK_SQLBUFFERPOOL分配为33Mb，为了显示这对我们的查询有何好处，我们将保留SET STATISTICS选项并再次运行查询并检查读取结果：

SELECT TOP 10000 * FROM Transactions 

Now we can see that SQL has not had to read or pre-fetch any pages from disk, all of our pages have been read from the cache/Buffer Pool which is a much faster form of data retrieval which clearly benefits our queries. As we haven’t had to perform any further population of the Buffer Pool, we’ve re-used pages then the memory clerk allocation will remain the same.

现在我们可以看到SQL不必从磁盘读取或预取任何页面，我们的所有页面都已从缓存/缓冲池中读取，这是一种更快的数据检索形式，显然使我们的查询受益。 由于我们不必执行任何其他的缓冲池填充操作，因此我们重新使用了页面，那么内存职员分配将保持不变。

We can see that from a cold cache our query of 10000 rows has quite naturally needed to fetch pages into the Buffer Pool via disk during execution but the key point is that the subsequent executions of the query have not used disk but have reused the stored pages.

我们可以看到，很自然地需要从冷缓存中查询10000行，以便在执行过程中通过磁盘将页面提取到缓冲池中，但是关键是查询的后续执行未使用磁盘，而是重用了存储的页面。

This is a high-level example of how SQL Server has been designed to store and retrieve data efficiently utilizing the Buffer Pool.

这是一个高级示例，说明如何使用缓冲池有效地设计和存储SQL Server。

It’s worth noting at this point that the execution times for both runs of the TOP 10000 query were identical even though we know that one has used the must faster cache and one used disk a lot more. This is down to the relatively small result set but it also shows that execution time is not really a 100% accurate way of testing a queries efficiency compared to both cost and IO statistic values.

值得注意的是，尽管我们知道一次使用了必须更快的缓存而一次使用了更多磁盘，但两次TOP 10000查询的执行时间是相同的。 这归因于相对较小的结果集，但它也表明与成本和IO统计值相比，执行时间并不是测试查询效率的100％准确的方法。

So going back to testing, what if we change our 10000 rows query to return 50000 rows this time?

那么回到测试，如果我们更改10000行查询以这次返回50000行怎么办？

Even though it is returning 5 times the amount of rows than the previous execution we aren’t seeing any of the reads or read-ahead reads coming from disk. However, the logical reads that were 61 in our previous execution are now at 229.

即使返回的行数是前一次执行的5倍，我们也看不到来自磁盘的任何读取或预读读取。 但是，在我们之前的执行中，逻辑读取为61，现在为229。

To understand why the query has been able to query more rows but still use cache we need to look at our IO statistics from the very first SELECT query that we ran:

要了解为什么查询能够查询更多行但仍使用缓存，我们需要从运行的第一个SELECT查询中查看IO统计信息：

This is all because of the earlier 4104 read-ahead reads; even though the pages were not required by the original query the mechanism has still pre-fetched a larger group of pages into memory than what the original query required.

这是因为较早的4104预读操作； 即使原始查询不需要页面，该机制仍将比原始查询所需的页面更多的页面预取到内存中。

In this example it has been a huge advantage to our subsequent queries, even when returning larger result sets, as they have utilised the pre-fetched cached pages rather than having use more expensive disk read operations.

在此示例中，即使返回较大的结果集，它对我们的后续查询也具有巨大优势，因为它们利用了预取的缓存页面，而不是使用了更昂贵的磁盘读取操作。

In this instance we are using very isolated testing examples and on busier systems our Buffer Pool could be under constant modification as different pages are being read into cache. This is one reason why our queries should be finely tuned with good code practice and the likes of sensible indexing so that we use the smallest amounts of rows/pages possible.

在这种情况下，我们使用的是非常孤立的测试示例，在繁忙的系统上，由于将不同的页面读入缓存，我们的缓冲池可能会不断修改。 这就是为什么我们的查询应该使用良好的代码习惯和明智的索引之类的方法进行微调的原因之一，以便我们使用尽可能少的行/页。

The SET STATISTICS_IO ON option is a great way to see how our queries are utilising Buffer Pool or physical IO operations. If we see high disk usage then we know there may be an opportunity for tuning or that there may be instance level reasons why the Buffer Pool is not being used as efficiently as it could be.

SET STATISTICS_IO ON选项是查看查询如何利用缓冲池或物理IO操作的好方法。 如果我们看到磁盘使用率很高，那么我们知道可能会有调整的机会，或者可能由于实例级别的原因，缓冲池的使用效率没有达到应有的水平。

翻译自: https://www.sqlshack.com/sql-server-buffer-pool-action/

sql 缓冲池