SQL Server为啥使用了这么多内存？

billpu

墨衍会员 · AI 创作全网分发码龄22年

关注

转载最新推荐文章于 2026-08-30 14:35:22 发布 759 阅读 AI 写同款· GEO 优化 ›

AI权益加码！Claude Code、Cursor等20+工具免费用！购周边限时加赠Coding Plan Lite，畅享主流AI工具！学习进阶更高效！阅读详情

今天微博上看到的,觉得很不错,立马转过来, 原文地址:http://support.microsoft.com/gp/anxin_techtip6/zh-cn

SQL Server的用户，常常会发现SQL进程使用了很多内存。这些内存大多数都是用来缓存用户要访问的数据，以达到最优的效率。那怎么能够知道哪些数据现在正缓存在内存中呢？其实，数据库管理员跑几句查询，就能得到答案。

谁占用了我的Buffer Pool?
我在做SQL Server 7.0技术支持的时候有客户问我,“我的SQL Server buffer pool很大,有办法知道是哪些对象吃掉我的buffer Pool内存么？比方说，能否知道是哪个数据库，哪个表，哪个index占用了buffer Pool么？”当时我没有找到这个问题的答案，但是我一直记着这个问题。直到SQL server 2005 版本出现，这个问题迎刃而解。答案就是使用动态视图（DMV） sys.dm_os_buffer_descriptors。这个DMV非常强大。根据SQL Server 联机丛书，这个视图的作用是　“返回有关 SQL Server 缓冲池中当前所有数据页的信息。可以使用该视图的输出，根据数据库、对象或类型来确定缓冲池内数据库页的分布”。具体点说，这个视图能够返回buffer pool里面一个8K 的data page的下列属性：
(1)该页属于哪个数据库
(2)该页属于数据库哪个文件
(3)该页的Page_ID
(4)该页的类型。可以根据这个来判断此页时索引页还是数据页
(5)该页内有多少行数据
(6)该页有多少可用空间。
(7)该页从磁盘读取以来是否修改过。
有了上面的信息，我们就可以很方便的统计出几种很有用的数据，如下。

1. Buffer Pool的内存主要是由那个数据库占了？

SELECT count(*)*8  as cached_pages_kb,CASE database_id
        WHEN 32767 THEN 'ResourceDb'
        ELSE db_name(database_id)
        END AS Database_name
FROM sys.dm_os_buffer_descriptors
GROUP BY db_name(database_id) ,database_id
ORDER BY cached_pages_kb DESC;

结果如下：

从上面的结果可以看到数据库AdventureWorks占用了大概30MB左右的缓冲池空间。
注意该DMV 并不返回Buffer Pool里面有关非数据页(如执行计划的缓存等)的信息。也就是说这个DMV并没有返回Buffer Pool里面所有页面的信息。
2. 再具体一点，当前数据库的哪个表或者索引占用Pool缓冲空间最多?

SELECT count(*)*8 AS cached_pages_kb
    ,obj.name ,obj.index_id,b.type_desc,b.name
FROM sys.dm_os_buffer_descriptors AS bd
    INNER JOIN
    (
        SELECT object_name(object_id) AS name
            ,index_id ,allocation_unit_id,object_id
        FROM sys.allocation_units AS au
            INNER JOIN sys.partitions AS p
                ON au.container_id = p.hobt_id
                    AND (au.type = 1 OR au.type = 3)
        UNION ALL
        SELECT object_name(object_id) AS name  
            ,index_id, allocation_unit_id,object_id
        FROM sys.allocation_units AS au
            INNER JOIN sys.partitions AS p
                ON au.container_id = p.partition_id
                    AND au.type = 2
    ) AS obj
        ON bd.allocation_unit_id = obj.allocation_unit_id
        LEFT JOIN sys.indexes b on b.object_id = obj.object_id AND b.index_id = obj.index_id
WHERE database_id = db_id()
GROUP BY obj.name, obj.index_id ,b.name,b.type_desc
ORDER BY cached_pages_kb DESC;

输出结果如下（部分）:

从上面的结果可以看到表Individual 在Pool内存里面缓冲最多，可能这个就是经常访问的热表，或者是比较大的表。注意Pool里面的缓冲页是经常变化的。你如果再跑一次语句，出现在头条的可能是另外一个表了。
3. Buffer Pool缓冲池里面修改过的页总数大小。这个比较容易：

SELECT count(*)*8  as cached_pages_kb,
       convert(varchar(5),convert(decimal(5,2),(100-1.0*(select count(*) from sys.dm_os_buffer_descriptors b where b.database_id=a.database_id and is_modified=0)/count(*)*100.0)))+'%' modified_percentage
        ,CASE database_id span>
        WHEN 32767 THEN 'ResourceDb'
        ELSE db_name(database_id)
        END AS Database_name
FROM sys.dm_os_buffer_descriptors a
GROUP BY db_name(database_id) ,database_id
ORDER BY cached_pages_kb DESC;

结果：

从上面的结果可以看到，AdventureWorks数据库大概有13.84%的数据是修改过的。如果一个数据库的大部分（超过80%）是修改过的，那么这个数据库写操作非常多。反之如果这个比例接近0，那么该数据库的活动几乎是只读的。读写的比例对磁盘的安排是很重要的。当然还有其他性能数据来获得数据库读写的大概比例，这里限于篇幅就不多谈了。