SQL Server 2008 R2资源控制器：资源池、工作负载组与分类器

简介：围绕 SQL Server 2008 R2 的 CPU 与内存分配优化，这份 DOCX 文档面向数据库管理员、解决方案供应商及需要处理多数据库资源争抢的技术人员，重点讲解资源控制器的管理思路与适用边界。内容对比 SQL Server 2005 中独立实例、处理器亲和性和服务器虚拟化等做法，说明资源池、工作负载组如何借助最小与最大百分比约束 CPU 和内存，并提及默认系统资源池、默认资源池、最小值总和不超过 100%、短时峰值以及分类请求需编写脚本等细节。资源包仅含 1 个 DOCX 文件，约 84KB，篇幅精炼，适合作为方案选型、参数理解和脚本编写前的背景查阅材料。已有 1355 人学习，读者可从中梳理多库环境下资源隔离、峰值控制和按负载分配资源的判断依据，也能为排查资源竞争、平衡系统性能与稳定性提供参考框架。

1. 一句话讲清：SQL Server 2008 R2 的资源分配到底在管什么

一台服务器上跑着好几个数据库，就像一间合租厨房里挤着三拨人同时开火：有人炖汤占着灶眼不放，有人只想烧壶水却连锅都找不到。SQL Server 2008 R2 里专门管这件事的组件叫资源控制器，它让管理员可以对 CPU 和内存做一次真正意义上的最大优化分配——不是凭经验拍脑袋，而是按“池”和“组”划出配额，并且给每个配额设上限和下限。在这之前，想让某个库多分点资源、某个库少占点，基本只能靠把实例拆开这种笨办法。搞懂这套机制，你才能判断服务器卡顿到底是哪一拨连接造成的，而不是对着一堆等待类型反复猜。

2. 多数据库挤在一台机器上，老办法为什么都不好使

2.1 只有一个库的时候，资源消耗根本不算问题

先把场景缩到最小。假设一台服务器只托管了一个数据库，那 CPU 和内存怎么被消耗，其实没人关心——反正整台机器的资源都是它的，跑满就跑满，慢一点也没人投诉。原文说得很直白：如果服务器上只托管了唯一一个数据库，SQL Server 的资源消耗并不是个严重的问题。

问题出在“多”上。一旦三五个库挤进同一个实例，它们面对的是同一组 CPU 核心、同一片内存池。业务库在白天处理下单，报表库在月末跑汇总，日志归档库在凌晨批量写入——它们的负载曲线不一样，峰值时间也不一样，但彼此完全不知道对方的存在，谁先抢到算谁的。

数据库恰恰是对资源格外敏感的一类应用。它不像静态文件服务那样，多几个请求就是多占一点带宽，慢一点用户也感觉不出来；数据库一旦拿不到 CPU 时间片，一条本来 20 毫秒的查询可能拖到 2 秒，业务方立刻就会找上门。而这类故障最难查的地方在于：你去看单条语句的执行计划，看不出任何毛病，因为它本身没问题，问题在它排队的时候前面插了一堆别人的活儿。

这里就引出一个很实际的诉求：能不能在“同一个实例内部”，让不同来源的连接各拿各的配额，而不是被迫拆机器？

2.2 处理器亲和度：分得出去，收不回来

在 SQL Server 2005 那个年代，业界比较接受的做法是：一个数据库配一个独立的 SQL Server 实例，然后用处理器亲和度把指定的几个 CPU 核固定分配给某个实例。

打个比方，这就像三个室友合租一套三居室，直接换锁——你的房间只有你能进，别人有钥匙也打不开。隔离性是够了，但代价是房间一旦空着，也永远不会给别人用。某个室友出差一个月，那间房就一直锁着落灰。

原文把这个毛病说得很清楚：一旦资源被分配给某个实例，它对其他实例就不可用了。结果就是，一个负载特别重的数据库，也没办法从其他实例那里临时借一点 CPU 过来，哪怕那些实例的核心正闲得发慌。

这种模式的隐性成本，做过容量规划的人大概都有一笔血泪经验：规划的时候只能按“每个库的峰值”去分核心，分完之后发现所有库的峰值加起来远超过机器实际能提供的核数。要么多买机器，要么降低隔离级别，两条路都不便宜。处理器亲和度本质上是一种静态分配，而业务负载是动态的，静态结构配动态需求，靠的就是不断加硬件来填坑。

2.3 虚拟化能隔离，但那层开销是实打实的

后来不少人转向另一种思路：一台虚拟机只装一个 SQL Server，一个虚拟机只跑一个库。资源隔离交给虚拟化层去做，看上去比处理器亲和度优雅得多。

它确实解决了“分出去收不回来”的一部分问题，因为在虚拟化层面做动态调整是可能的。但原文点出了两个绕不开的代价。

第一个代价是看得见的：每台虚拟机自己还要跑一套操作系统，这套系统本身就在消耗 CPU 和内存，而这些资源本来是可以全部给数据库用的。一台物理机切成四台虚拟机，实际能被 SQL Server 拿到的算力，一定小于物理机直装一个实例。这个折扣平时不显眼，等到业务量上来、机器开始喘的时候，就很刺眼了。

第二个代价是看不见的：能不能做按需的动态分配，完全取决于你用的是什么虚拟化软件。有的能做，有的做起来很别扭，有的干脆做不到。这就导致方案的可移植性很差——换一套底层环境，原来的资源策略可能整套作废。

两条老路各有各的堵点：处理器亲和度太死，虚拟化太绕。共同缺的是一样东西——在同一个实例内部，按连接来源做动态的、可配置的资源切分。SQL Server 2008 R2 引入的资源控制器，补的就是这个缺口。

3. 资源控制器怎么运转：资源池、工作负载组、分类器三层

3.1 资源池：先给整台服务器切盘子

资源池是整个机制的地基。原文的定义很朴素：资源池是服务器资源的集合，这些资源在池内对工作组是可用的。换个说法，就是把整台机器的 CPU 和内存当成一个总盘子，先横着切成几大块，每块就是一个池。

每个池都被配置了 CPU 资源和内存资源的最小值和最大值，用百分比表示，100% 代表服务器的整个硬件资源。这个百分比是理解后面所有细节的钥匙，第 4 章会专门展开，这里先记住它是“相对整机”的比例，不是“相对某个库”的比例。

默认情况下，SQL Server 2008 R2 里预置了两个资源池：

这个设计有点像一个写字楼的总配电。系统资源池是消防和电梯的专用回路，你不能去动它；默认资源池是公共区域的插座，谁插上都行；自建资源池则是你给某个部门单独拉的一路线，闸刀在自己手里。

值得留意的是，池子是“逻辑上的切分”，不是“物理上的绑定”。池的边界不是一堵墙，更像一条画在地上的线——资源闲置的时候，谁都可以走过去用，只是不能越过自己那条上限。

3.2 工作负载组：池子里的小隔间

光有池还不够细。一个池里面往往还得分几类活儿，这时候就要用到工作负载组。原文说，每个资源池都包含负载工作组，默认的两个池各带一个组。

组是请求真正“坐”的地方。池决定了这堆请求总共能用多少资源，组决定了这堆请求内部怎么排座次。

打个比方：资源池是小区的总水表，工作负载组是每家每户的分水表。总表定的是这个小区能拿多少吨水，分表定的是谁家先用、谁家能多接一点。同一个池里放多个组，等于在一个总表下面挂了几只分表，管理粒度更细。

这样的结构带来一个很实用的能力：你可以把不同类别的数据库请求放进不同的组合池，而不是被迫在数据库这个级别上做资源分配。原文举的例子是——与其平均分配，不如把更多的 CPU 时间给数据库查询类的操作，而不是给写数据库的操作。这句话背后的意思是，资源分配的单位从“库”下沉到了“请求来源”，这是一次粒度上的实质变化。

3.3 分类器函数：请求进门时的那道安检

前两层都是“静态的容器”，真正让这套机制动起来的是分类器。

资源控制器在处理请求时，会根据请求的特性把请求分配给合适的工作负载组。这个“判断”动作，由一段你自己写的函数来完成，它返回一个组名，引擎就照这个名字把连接塞进去。

问题是，这个判断发生在连接建立的那一刻，而不是每条语句执行的时候，也不是每次事务提交的时候。这一点极其关键，后面讲误区时会再提一次。分类器能看到的，是这条连接身上带的标签：登录名、来源主机名、应用程序名。它看不到“这条语句是查询还是写入”。

那么“按请求类型分配资源”怎么落地？答案是靠标签区分来源。让报表系统用一个专用登录名连进来，让下单系统用另一个登录名连进来，分类器按登录名一判断，两类流量就进了不同的组。同一个应用如果既查又写，想分开就得在应用侧准备不同的连接串——这算是一点工程量，但换来的是非常干净的资源隔离。

下面是一段能跑通的最小骨架，分四步：

-- 第一步：建一个资源池，把 CPU 和内存的上下限都写清楚 CREATE RESOURCE POOL Pool_Report WITH ( MIN_CPU_PERCENT = 10, -- 保底 10% 的 CPU MAX_CPU_PERCENT = 40, -- 最多用到 40% 的 CPU MIN_MEMORY_PERCENT = 10, -- 保底 10% 的内存配额 MAX_MEMORY_PERCENT = 40 -- 最多用到 40% 的内存配额 );

这一步的参数含义很直白：MIN 系列是池子无论如何都能拿到的那一份，MAX 系列是它伸手能够到的天花板。四个值都按整机百分比计，10 和 40 意味着这个池最惨的时候有 10% 保底，最横的时候也只能占 40%。

-- 第二步：在这个池里开一个工作负载组 CREATE WORKLOAD GROUP WG_Report WITH ( IMPORTANCE = HIGH -- 同一池内资源紧张时，这个组优先拿资源 ) USING Pool_Report;

IMPORTANCE 是组级别的优先级，取值从 LOW 到 HIGH。它的作用范围只在池内部：池分到的那份资源不够分的时候，HIGH 的组排在前面。池和池之间不靠这个参数竞争，靠的是各自的 MIN 和 MAX。

-- 第三步：写分类器函数，决定新连接去哪个组 USE master; GO CREATE FUNCTION dbo.fn_Classify() RETURNS sysname WITH SCHEMABINDING AS BEGIN DECLARE @grp sysname; -- 报表专用账号：进报表组 IF SUSER_SNAME() = N'report_login' SET @grp = N'WG_Report'; -- 其他所有连接：进默认组，保持原样 ELSE SET @grp = N'default'; RETURN @grp; END; GO

函数必须标记 SCHEMABINDING，返回类型是 sysname，也就是组名。里面可以用的判断依据包括 SUSER_SNAME()、HOST_NAME()、APP_NAME() 这类会话级信息。返回值必须是已经存在的组名，写错一个字，连接就会被兜底扔进默认组——而且不会报错，这是排查时最容易翻车的地方之一。

-- 第四步：把分类器挂上去，然后重新配置使其生效 ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fn_Classify); GO ALTER RESOURCE GOVERNOR RECONFIGURE; GO

ALTER RESOURCE GOVERNOR RECONFIGURE 这句不能省。前面的建池、建组、改配置都只是写进了元数据，必须执行一次 RECONFIGURE，配置才真正落地。这一步的代价是会短暂中断现有连接，所以别在业务高峰做。

整个流程走完，一个报表系统的连接进来，会被分类器认出来，塞进 WG_Report 组，这个组又归 Pool_Report 池管，池的上下限就是它最终能拿到的资源范围。三层各司其职，逻辑上相当清爽。

清爽归清爽，原文也点出了它最大的不便：这不是一个点几下鼠标就能配好的管理工具。分类处理请求、把请求转发到合适的负载工作组，需要编写大量脚本。图形化管理工具里能看到这些节点，能看到运行状态，但要新建一个完整的池加组加分类器，还是得回到 T-SQL。这一点劝退了不少人，也直接导致了后面要说的那些误解。

4. 最小值和最大值：两个百分比，两套脾气

4.1 最小值是保底承诺，不是提前占住的空房

很多人第一次看到 MIN_CPU_PERCENT = 10 这种写法，第一反应是“那我先给这个池留 10% 的 CPU，别人用不了”。这个理解偏得不算离谱，但方向错了。

原文的表述是：池的最小值表示这部分资源是专门分配给池的，而且对于该池是一直可用的。注意“可用”两个字——它是站在池的角度说的，意思是“你需要的时候一定能拿到”，不是“你不需要的时候别人也不能用”。

真实的行为更接近这样：当所有池都有活儿干、资源开始紧张时，每个池至少有自己那份最小值兜底，不会被别人挤成零；而当某个池闲着的时候，它那份最小值并不会变成一堵墙，那些资源会流到正在干活的池那边去。

打个比方，这像餐厅给常客留的位子。客人没来的时候，位子是可以给散客坐的；客人一进门，位子立刻腾出来。留位子不等于空着位子。

这里有一条硬约束：所有池声明的最小值加起来不能超过 100%。这很好理解，保底承诺的总和如果超过整机，那承诺本身就不成立了，引擎会直接拒绝这样的配置。而任何没有被最小值声明保护的资源，则可以自由地跨所有资源池流动。

所以在做容量规划时，最小值应该按“这个业务最差情况下必须保证多少”来定，而不是按“它平时大概用多少”来定。前者是保险，后者是平均线，两者搞反了，配置就会又浪费又不起作用。

4.2 最大值是天花板，但它允许你短暂顶到 100%

另一个常见的期待是：设了 MAX_CPU_PERCENT = 40，那这个池就永远不可能超过 40% 了，监控上看到 41% 就是配错了。

原文对这一点有明确提醒：尽管可以设置任何最大值，池也有可能触发简短的 CPU 百分之百高峰，这些高峰不会带来问题，被认为是正常行为。

原因要从 CPU 使用率这个指标本身说起。它不是一个“当前瞬时值”，而是在一个采样窗口里算出来的统计量。窗口的边界和池的资源调度周期不完全对齐，就会出现这样的画面：某个采样窗口里，池在用完自己那份配额之前刚好抢到了几个时间片，平均值一算，读数冲上了 100%。

所以看监控的时候要有心理准备：最大值管的是“长期平均意义上的上限”，不是“任何一毫秒都不得越过的红线”。一个池在绝大多数时间段贴着 35% 到 40% 走，偶尔冒出一两个 100% 的尖峰，这是健康的；反过来，如果它长期稳定在 40% 以上不回落，那才说明配置没生效，或者分类器把不该进来的连接放进来了。

内存的情况类似，甚至更明显。因为内存配额的判定是按查询申请内存授予的时机来做的，一个组在某一刻集中申请，读数也会跳。

4.3 CPU 百分比和内存百分比，说的其实不是一回事

这是整篇里最值得单独拎出来讲的一点，也是最容易搞混的一点。

CPU 的百分比，含义比较直观：整台机器可用的 CPU 算力中，这个池能占到多大比例。池和池之间抢的是处理器时间。

内存的百分比，约束的却不是“这个池能缓存多少数据页”。资源控制器里的内存配额，管的是查询在运行过程中申请的那部分工作区内存——比如排序、哈希连接需要临时开辟的空间。至于缓冲池怎么用、数据页缓存多少，那是另一套机制在管，不在资源控制器的手里。

这个区别的实际意义非常大。很多人以为给某个池设了 MAX_MEMORY_PERCENT = 30，就等于把这个库的缓冲池锁死在 30%，从此它不会把别人的缓存挤出去。这个期待会落空。真正会发生的是：当这个池里的查询要申请大块内存做排序时，它最多只能拿到 30% 的份额，超了就排队等，或者降级执行。

把这两行记牢，很多“配置了但看起来没用”的困惑会自动消解。配置没生效，和配置生效了但作用点不在你以为的地方，是两种完全不同的情况，排查方向也完全不同。

5. 几个容易搞混的地方：别把资源控制器当成万能的闸门

5.1 误区一：把最小值当成“预留但闲置”的资源

易混点：MIN_CPU_PERCENT 看起来像是在机器上划走一块地，插个牌子写“专用”。

为什么混：字面上“最小值”很像“保底份额”，而保底这个词在日常语境里往往意味着独占。加上配置界面里明明白白写着百分比，更像是在做物理切分。

怎么区分：看它闲置时的表现。如果某个池没有连接，那它那份最小值并不会被锁住，其他池照样能用。真正的独占是处理器亲和度那种模式，资源控制器不是。所以容量规划时不应该把各池最小值简单相加去估算“还能剩多少给新业务”，那个加法在资源空闲时没有意义。

5.2 误区二：以为设了最大值就绝对不会出现 100%

易混点：MAX_CPU_PERCENT = 40 被理解成“这道闸门只能过 40% 的水”。

为什么混：百分比这个单位天然给人一种精确感，加上配置项本身写得斩钉截铁，很容易让人以为越线就是配置错了。

怎么区分：看时间尺度。短时间的尖峰是统计方式造成的，属于原文所说的正常行为；长时间的越线才是问题。判断标准不是“有没有出现过 100%”，而是“在一个完整的业务周期里，它有没有持续超出上限”。看到尖峰就去改配置，往往是把好好的东西调坏了。

5.3 误区三：以为它能像限流器一样精细控制每条语句

易混点：把资源控制器当成一个能“卡住慢查询”的工具，期待它按语句级别限流。

为什么混：名字里带“控制”，功能描述里又说“按请求特性分配”，听起来像是能对每一条 SQL 单独动手。

怎么区分：看分类发生的时机。分类器只在连接建立时执行一次，之后这条连接上的所有语句都在同一个组里跑。也就是说，同一个连接里既跑快查询又跑大报表，资源控制器分不开它们。想分开，得在应用侧用不同账号、不同连接串连进来。至于单条语句的执行时间控制、执行计划干预，那是另外的机制，不在资源控制器的职责范围内。

5.4 误区四：以为图形界面点几下就能配完

易混点：管理工具里确实能看到“资源调控器”这个节点，点开还有池和组的列表，看上去像是可视化配置。

为什么混：界面能展示状态，容易顺推为也能完成配置。加上很多数据库功能确实是右键新建就完事，惯性思维会带过来。

怎么区分：真去建一个试试。新建池要写语句，新建组要写语句，最关键的分类器函数必须手写，最后还得执行一次重配置。原文的措辞是“需要编写大量脚本”，这不是客套话。图形界面在这里的角色更接近“仪表盘”，不是“方向盘”。

6. 该用和不该用：一条判断线，加一个反例

把前面几章收拢成一句可操作的话：当一台服务器上跑着多类来源不同、优先级不同、峰值时间还错开的数据库连接，而你又不想为此拆实例或拆虚拟机时，资源控制器值得上。反过来，只有一个库、或者所有连接都来自同一个应用同一个账号时，它基本帮不上忙。

具体的分界线可以看这张表：

举个具体例子。某公司的订单库和月度报表库共用一个实例，报表任务一开跑，订单接口的响应时间就从 80 毫秒涨到 900 毫秒。改造路径是这样的：给报表系统单独开一个登录名，建一个 Pool_Report 资源池，最小值给 10%、最大值给 40%，池里放一个 WG_Report 组，分类器按登录名判断，剩下的连接走默认组。上线之后，报表最忙的时候也只在自己那 40% 里折腾，订单侧的响应时间回到了两位数毫秒。至于报表本身慢了一点——这本来就是应该付出的代价，它不该免费占用别人的资源。

反过来的例子也很典型。有人一上来就想给六个业务各建一个池，每个池最小值写 20%，六个加起来 120%，配置直接被拒。还有人把分类器写好了，忘了执行重配置，盯着监控看了两天，坚信“这功能没用”。这类翻车大多不是机制复杂，而是没把最小值的总和不超 100%、配置必须重配置生效这两条硬规则记在心上。

从那以后我每次动资源控制器，都会强制走一遍固定顺序：先把各池最小值在纸上加一遍确认不超过 100%，再确认分类器返回的组名和实际建的组名一字不差，最后在低峰期执行重配置，并盯着监控看半小时再走人。顺序错一步，后面全是玄学。希望帮到你。

本文还有配套的精品资源，点击获取