SQL Server 2008 R2 资源调控器：多库单实例CPU与内存分配避坑

简介：面向SQL Server数据库管理员与解决方案供应商的专题文档，聚焦SQL Server 2008 R2中CPU和内存资源的分配与优化。内容围绕资源控制器展开，对比SQL Server 2005中处理器亲和性、独立实例及服务器虚拟化等旧方案，说明资源池的最小值与最大值如何设定、默认系统池与默认池的作用，以及工作负载组如何按请求特性分类并分配资源，并提示最小值总和不超过100%、短暂CPU峰值属正常现象等要点。文档还提及通过SQL Server Management Studio管理资源池、借助脚本实现细粒度控制及查阅MSDN资料的思路，适合需要处理多数据库资源争抢、提升实例稳定性的技术人员参考。资源包共1个docx文件，约84KB，篇幅紧凑，便于快速检索关键概念与方案对比。已有1355人学习，可作为SQL Server 2008 R2资源调控器入门及优化思路整理的参考资料。

1. 五个库挤一台机器，结账日必挂：这道闸到底怎么装

一台 32 核、128 GB 内存的物理机，上面并排跑着五个业务库。平时相安无事，一到月底结账那天，报表库的一条大聚合查询就把 CPU 顶到 95% 以上，订单库的写入开始排队，前端超时告警响成一片。运维的第一反应是加机器，第二反应是把报表库拆出去，这两个动作都要钱、要时间，而且拆完之后新机器大部分时间是闲着的。SQL Server 2008 R2 里那套资源调控器，就是为这种「一台实例上几个库抢同一份 CPU 和内存」的场面准备的，它把 SQL Server 2008 R2 CPU 和内存最大优化分配这件事，从「换硬件」拉回到「配策略」。这篇笔记拆的就是这套机制：三层结构怎么理解、脚本怎么写、百分比到底相对谁算、分类器函数踩过哪五个坑。手上有多个库挤在一台实例上、又暂时不打算做实例拆分或虚拟化拆分的同行，可以直接照着改脚本落地。

2. 资源调控器的三层结构：池、组、分类器各管什么

2.1 处理器亲和性这条路为什么走不通

SQL Server 2005 时代比较标准的做法是「一库一实例加处理器亲和性」。用affinity mask把某几个 CPU 核固定分配给某个实例，实例之间物理隔离，互不干扰。这套方案在纸面上很清晰，问题出在它的分配方式：固定切分之后，分配给 A 实例的 8 个核，B 实例在 A 完全空闲时也一个都用不上。月底报表库把它那 8 个核吃满，订单库那边的 8 个核闲着，整机 CPU 利用率看着只有一半，订单库照样排队。资源的刚性切分换来了隔离，代价是整体利用率。

第二个代价是多实例本身的固定开销。每个实例一套独立的缓冲池、独立的计划缓存、独立的后台服务、独立的 tempdb，再加上独立的备份作业窗口和补丁窗口。一台 32 核的机器切出 5 个实例，等于 5 份固定成本，内存被切得很碎，每个实例的缓冲池都不够大，缓存命中率集体下滑。这套做法在数据库数量少、负载特征差异极大的场景还能忍，一旦库里超过三四个，运维复杂度是成倍上涨的。

虚拟化那条路的逻辑类似：一台虚拟机一个实例，隔离性更好，管理上也能做快照和迁移。但 hypervisor 和几套 guest 操作系统先吃掉一块 CPU 和内存，剩下才轮到数据库。更麻烦的是内存的按需分配，数据库最怕的就是运行中内存被上层抽走，缓冲池被压缩，物理读立刻飙升。资源要在实例之间动态流动，在虚拟化层做粒度太粗、反馈也太慢，一层层调度下来，等资源到位，业务高峰已经过去了。

2.2 池是预算，组是队列，分类器是闸机

资源调控器换了个思路：不再在操作系统层面切核，而是在实例内部按会话分流，一共三层对象。

资源池（Resource Pool）是预算科目。每个池声明自己能拿多少 CPU 和多少内存，用百分比表示。实例上可以建多个池，各池的预算互相独立，但都从同一份实例总资源里出。默认定义了两个池：internal 是系统独占的，跑的是 SQL Server 自己的后台任务，改不了也删不掉；default 是兜底池，所有没被分类器函数认领的会话全落在这里。

工作负载组（Workload Group）是池里的队列。一个池下面可以挂多个组，组是会话的实际容器，真正接请求的是组，池只是给组发预算。组上还能再设一层策略，比如优先级、单请求的最大内存授予比例、单请求的 CPU 时间上限、组的最大并发请求数。可以这么理解：池决定「这一摊子总共能用多少」，组决定「这摊子里谁的请求先跑、单个请求能占多少」。

分类器函数（Classifier Function）是闸机。它在会话登录阶段执行一次，返回一个组名，这个会话后续的所有请求就都归到那个组、进而归到那个池。整个机制的关键就在这一层——分流的准确性完全取决于这个函数写得对不对。

三层职责可以对照着看：

层级	对象类型	管什么	典型配置项
资源池	RESOURCE POOL	CPU 与查询内存的总预算	MIN_CPU_PERCENT、MAX_CPU_PERCENT、MIN_MEMORY_PERCENT、MAX_MEMORY_PERCENT
工作负载组	WORKLOAD GROUP	组内请求的排队与单请求上限	IMPORTANCE、REQUEST_MAX_MEMORY_GRANT_PERCENT、REQUEST_MAX_CPU_TIME_SEC、GROUP_MAX_REQUESTS、MAX_DOP
分类器函数	标量函数	会话到组的映射规则	返回值必须是已存在的组名

先把这张表记住，后面所有脚本都是围绕这三层展开的。很多配置翻车并不是参数设错，而是把「池的预算」和「组的策略」搞混了，比如想限制单条查询的 CPU 时间，却去改池的MAX_CPU_PERCENT，那当然没效果。

2.3 最小值和最大值的真实语义

MIN_CPU_PERCENT是争用时的保底值，不是预留。CPU 空闲的时候，某个池完全可以超过它的最小值去用资源，最小值只在多个池同时抢 CPU 时才起作用——资源调控器会保证每个池至少能拿到它声明的那个百分比。所有池的最小值加起来不能超过 100%，超了RECONFIGURE会直接报错，这条限制在规划阶段就得算清楚。

MAX_CPU_PERCENT是软上限，不是硬限。原文里那句话很关键：即使设置了最大值，池也有可能触发短暂的 CPU 百分之百高峰，这属于正常行为。原因在于资源调控器的调节是按调度周期采样和调整的，不是毫秒级的硬性截断。做容量规划时不要把最大值当成绝对天花板，配额算到 70% 左右要留出余量，否则高峰期的瞬时冲高还是会影响同实例的其他池。

内存那两个百分比是最容易被误解的地方。SQL Server 2008 R2 的资源调控器管的「内存」是查询执行内存授予，也就是排序、哈希连接、并行交换这类算子需要的工作区内存，不是缓冲池。把某个池的MAX_MEMORY_PERCENT压到 20%，不会让这个池里的会话只能缓存 20% 的数据页，它影响的是查询内存授予的额度和授予排队行为。想靠这个参数去限制某个库占用的缓冲池大小，方向就错了，那个要靠max server memory加上业务侧的访问模式来调。

还有一点：百分比的计算基数不是物理内存，是实例的max server memory配置值。物理机 128 GB、max server memory设成 100 GB，那么MIN_MEMORY_PERCENT = 50意味着 50 GB 的查询内存预算，而不是 64 GB。这个基数在改配置的时候必须确认一遍，否则算出来的数字和实际差一截。

3. 建池建组：一份可以直接改名的 T-SQL 脚本

3.1 配置之前先采集：三个基线数字

拍脑袋定百分比是这类配置最常见的失败原因。动手建池之前，至少要有三个数字：每个库的 CPU 消耗相对排序、每个库的查询内存授予峰值、业务方能够接受的最差响应时间。前两个从实例里就能捞出来，第三个只能去问业务。

CPU 消耗的相对排序可以这么抓：

-- 按数据库汇总计划缓存里的 CPU 消耗，用于确定谁该进哪个池 SELECT DB_NAME(st.dbid) AS db_name, SUM(qs.total_worker_time) / 1000000.0 AS total_cpu_sec, SUM(qs.execution_count) AS exec_count, SUM(qs.total_worker_time) / NULLIF(SUM(qs.execution_count), 0) / 1000.0 AS avg_cpu_ms FROM sys.dm_exec_query_stats AS qs CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st GROUP BY st.dbid ORDER BY total_cpu_sec DESC;

total_worker_time的单位是微秒，除以 1000000 换算成秒；avg_cpu_ms是单次执行的平均 CPU 毫秒数，这个值比总量更能说明「谁的单条语句重」。这张视图只覆盖计划缓存里的语句，实例重启或者计划被挤出去之后数据会丢，所以要在业务高峰前后各抓一次做对比。它给的是相对排序，不能直接拿来当配额数字用。

查询内存授予的峰值要靠性能计数器，SQLServer:Memory Manager\Memory Grants Outstanding（当前已授予的查询内存数）和Memory Grants Pending（等待授予的请求数）。后者长期大于 0，说明内存授予已经在排队，这时候再去压某个池的MAX_MEMORY_PERCENT只会让排队更严重。采集周期至少覆盖一个完整的业务日，月度结账这类场景要单独抓一次。

3.2 创建资源池与工作负载组

假设按业务特征分三类：订单类 OLTP 库、报表分析库、夜间跑批的 ETL。规划是 OLTP 保底 50%、上限 80%，报表保底 20%、上限 40%，ETL 保底 10%、上限 30%。CPU 最小值加起来 80%，内存最小值也一样，都给 100% 留了 20% 的余量给 default 池和系统任务。

USE master; GO -- 启用资源调控器（需要 show advanced options） EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'Resource Governor', 1; RECONFIGURE; GO -- 订单类：保底高、上限宽，保证结账日也不被挤死 CREATE RESOURCE POOL pool_oltp WITH ( MIN_CPU_PERCENT = 50, MAX_CPU_PERCENT = 80, MIN_MEMORY_PERCENT = 50, MAX_MEMORY_PERCENT = 80 ); GO -- 报表类：保底低、上限收紧，允许它用闲着的资源但抢不过订单 CREATE RESOURCE POOL pool_report WITH ( MIN_CPU_PERCENT = 20, MAX_CPU_PERCENT = 40, MIN_MEMORY_PERCENT = 20, MAX_MEMORY_PERCENT = 50 ); GO -- 跑批类：优先级最低，主要吃夜间空闲窗口 CREATE RESOURCE POOL pool_batch WITH ( MIN_CPU_PERCENT = 10, MAX_CPU_PERCENT = 30, MIN_MEMORY_PERCENT = 10, MAX_MEMORY_PERCENT = 30 ); GO

三个池的MIN_CPU_PERCENT之和是 80%，MIN_MEMORY_PERCENT之和同样是 80%，都在 100% 以内。这条约束不是建议而是硬性的，加起来超了RECONFIGURE阶段会直接拒绝。留出的 20% 不是浪费，default 池里的会话（比如没被分类器识别的临时连接、运维工具连进来的会话）还得靠这部分跑。

内存上限那边，报表池给了 50% 而 CPU 上限只给 40%，这是故意的：报表查询的瓶颈通常在排序和哈希的内存授予上，不在 CPU，把内存上限放宽一点能减少它溢出到 tempdb 的概率，而 CPU 上限压紧能防止它把调度器占满。

池建好之后是组：

-- 订单组：高优先级，单请求内存授予不超过池的 25% CREATE WORKLOAD GROUP wg_oltp WITH ( IMPORTANCE = HIGH, REQUEST_MAX_MEMORY_GRANT_PERCENT = 25, REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 30, REQUEST_MAX_CPU_TIME_SEC = 0, GROUP_MAX_REQUESTS = 0, MAX_DOP = 4 ) USING pool_oltp; GO -- 报表组：中优先级，单请求可以拿池的一半内存，避免大聚合反复排队 CREATE WORKLOAD GROUP wg_report WITH ( IMPORTANCE = MEDIUM, REQUEST_MAX_MEMORY_GRANT_PERCENT = 50, REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 60, REQUEST_MAX_CPU_TIME_SEC = 0, GROUP_MAX_REQUESTS = 20, MAX_DOP = 2 ) USING pool_report; GO -- 跑批组：低优先级，并发数卡死，别让它把连接数吃光 CREATE WORKLOAD GROUP wg_batch WITH ( IMPORTANCE = LOW, REQUEST_MAX_MEMORY_GRANT_PERCENT = 20, REQUEST_MEMORY_GRANT_TIMEOUT_SEC = 30, REQUEST_MAX_CPU_TIME_SEC = 0, GROUP_MAX_REQUESTS = 10, MAX_DOP = 1 ) USING pool_batch; GO

逐项说一下这几个参数的实际含义。IMPORTANCE只在同一个池内部比较有效，跨池没有意义，所以三个组各自设了不同值但实际不会互相影响，真正的隔离是池那一层做的。REQUEST_MAX_MEMORY_GRANT_PERCENT是单条查询能拿到的内存占池内存预算的比例，报表组给到 50% 是因为它的典型查询就是大聚合，给少了会一直等授予；订单组给 25% 是因为 OLTP 的单条语句本来就轻，给多了反而让少量慢查询占住额度。REQUEST_MAX_CPU_TIME_SEC设 0 表示不限制，这个参数在 2008 R2 里只对 CPU 时间做统计和取消，不适合用来做精细限流，真要限流还是靠池的MAX_CPU_PERCENT，别指望它。GROUP_MAX_REQUESTS是组内并发请求上限，跑批组设 10 是为了防止 ETL 一次性开几百个连接把实例的总连接数吃满。MAX_DOP在组级别覆盖实例的max degree of parallelism，报表组给 2、跑批组给 1，都是为了减少并行查询对调度器的冲击。

提示：MAX_DOP在组上设了之后，这个组里所有查询都按这个值走，包括那些原本靠并行跑得很快的语句。上线前拿几条典型语句在测试实例上对比一下耗时，别一刀切。

3.3 分类器函数与启用顺序

分类器函数必须是带SCHEMABINDING的标量函数，返回值类型是SYSNAME，返回的字符串必须是已存在的组名。下面这版按登录名分流，是最简单也最不容易出错的一种：

USE master; GO CREATE FUNCTION dbo.fn_rg_classifier() RETURNS SYSNAME WITH SCHEMABINDING AS BEGIN DECLARE @grp SYSNAME; -- 报表账号固定进报表组 IF SUSER_SNAME() = 'svc_report' SET @grp = 'wg_report'; -- ETL 账号进跑批组 ELSE IF SUSER_SNAME() = 'svc_etl' SET @grp = 'wg_batch'; -- 其余一律进订单组 ELSE SET @grp = 'wg_oltp'; RETURN @grp; END; GO -- 挂上分类器函数并生效 ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fn_rg_classifier); GO ALTER RESOURCE GOVERNOR RECONFIGURE; GO

执行顺序不能乱：先建池，再建组（组要USING指定的池），再建分类器函数，最后才ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = ...)加RECONFIGURE。跳过前面的步骤直接挂函数，会因为没有目标组而报错。改完函数之后，只有新建立的连接才会重新分类，已经存在的连接保持在原来的组里，这一点在后面的排查章节还会遇到。

验证配置是否落地的第一条命令是查配置视图：

SELECT * FROM sys.dm_resource_governor_configuration;

is_enabled必须是 1，classifier_function_id不能是 0。这两项有一个不对，后面所有配额都不会生效，而 SSMS 界面上看上去一切正常，这是最耗时间的一种「没报错但没效果」。

4. 请求分流：分类器函数能读到什么、读不到什么

4.1 分类器函数的执行时机与可用上下文

分类器函数在会话建立阶段执行一次，返回组名之后就再也不执行了，后续这个会话上的所有请求都按这个组走。这个「只执行一次」的特性决定了它的写法约束：函数必须足够快，因为它挡在每个新连接的前面；函数里不能有不确定的行为，因为同一个会话不会重新判一次。

执行时的数据库上下文是 master，不是在用户库里。这意味着DB_NAME()返回的往往是 master 而不是你以为的那个业务库。这一点值得单独强调，很多按库分流的方案在这里翻车：想用DB_NAME() = 'ReportDB'判断报表流量，结果所有连接都被判成 master，全部落进 default 池，配额形同虚设。要按来源分流，得用那些在登录阶段就能拿到的信息。

可用的上下文函数有这么几个：SUSER_SNAME()返回登录名，SUSER_SID()返回登录的 SID，APP_NAME()返回连接字符串里声明的应用程序名，HOST_NAME()返回客户端机器名，HOST_PROCESS_ID返回客户端进程号，IS_SRVROLEMEMBER()可以判断登录是否属于某个服务器角色。这几个函数在分类阶段都能正常取值，是分流规则的主要素材。

函数体里不能做的事也得记住：不能查表、不能调存储过程、不能引用视图。一旦在里面写了SELECT，每条新连接都要去读一次表，表上有锁就排队，高峰期直接把登录拖慢，严重的时候能把自己锁死。规则尽量写成简单的字符串比较，匹配逻辑复杂的分流需求，宁可让应用侧在连接字符串里带上不同的Application Name，也别在分类器函数里做数据库查询。

4.2 三种实用分流策略

按登录名分流最直接，适合每类业务有独立服务账号的场景。上面 3.3 那版脚本就是这个思路，规则清晰、几乎零维护成本，缺点是同一类业务里想再细分就没抓手了。

按应用名分流适合一套服务账号跑多个应用的场景。让各应用在连接字符串里显式声明Application Name，分类器按APP_NAME()判断：

ALTER FUNCTION dbo.fn_rg_classifier() RETURNS SYSNAME WITH SCHEMABINDING AS BEGIN DECLARE @grp SYSNAME; DECLARE @app NVARCHAR(128) = APP_NAME(); -- 连接串里带 ReportSvc 的走报表池 IF @app LIKE 'ReportSvc%' SET @grp = 'wg_report'; -- 带 EtlJob 的走跑批池 ELSE IF @app LIKE 'EtlJob%' SET @grp = 'wg_batch'; -- 其余走订单池 ELSE SET @grp = 'wg_oltp'; RETURN @grp; END; GO

APP_NAME()取的是连接字符串里Application Name或app参数的值，没设的话返回空串或者驱动默认值。LIKE 'ReportSvc%'用前缀匹配是为了兼容同一应用的不同版本后缀。这种写法的好处是分流规则跟着应用走，应用迁移或者换账号都不影响分类结果；代价是要推动应用侧改连接字符串，跨团队协作时推进速度取决于沟通。

按主机名分流适合「同一批作业从固定几台跳板机或应用服务器发起」的场景，用HOST_NAME()匹配。这种规则最脆弱，机器一换、容器一重建，主机名就变了，规则悄悄失效，流量全落进 default 池。我一般只在临时排查或者过渡期用这种方式，不作为长期方案。

三种策略可以叠加，判断顺序从具体到宽泛：先按登录名精确匹配服务账号，再按应用名前缀兜一层，最后全部落到默认组。顺序反了就会出现「某个特殊账号被宽泛规则先截走」的情况。

4.3 验证分流是否生效

配置改完之后不要凭感觉，直接查会话落在哪个组：

-- 看当前所有用户会话实际归属的组和池 SELECT s.session_id, s.login_name, s.program_name, s.host_name, g.name AS group_name, p.name AS pool_name FROM sys.dm_exec_sessions AS s JOIN sys.dm_resource_governor_workload_groups AS g ON s.group_id = g.group_id JOIN sys.dm_resource_governor_resource_pools AS p ON g.pool_id = p.pool_id WHERE s.is_user_process = 1 ORDER BY p.name, g.name;

group_id是会话和组之间的唯一纽带，这张表能一眼看出每个连接的实际归属。如果某个本该进报表组的会话落在default组里，先看它的program_name和login_name是不是符合分类器里的判断条件，再看这个连接是不是在函数修改之前就建立的——老连接不会重新分类。

再看池层面的资源使用：

-- 池维度的 CPU 与内存使用快照 SELECT p.name AS pool_name, p.min_cpu_percent, p.max_cpu_percent, p.min_memory_percent, p.max_memory_percent, rg.total_cpu_usage_ms, rg.total_cpu_violation_sec, rg.total_memory_grant_count, rg.active_memory_grant_count FROM sys.dm_resource_governor_resource_pools AS p JOIN sys.dm_resource_governor_resource_pool_volumes AS rg ON p.pool_id = rg.pool_id;

total_cpu_violation_sec这个字段值得盯，它统计的是池超出上限被限制的累计秒数。数值持续增长说明上限压得太紧，业务已经在受影响；一直为 0 说明上限还有放宽空间，或者这个池根本没在抢资源。active_memory_grant_count持续走高配合应用侧的超时告警，说明池的内存配额不够。

5. 避坑与排查：五条踩过的记录与对应的诊断脚本

5.1 现象：改了分类器函数，新连接还是进 default 组

现象是改完函数、执行了RECONFIGURE，sys.dm_exec_sessions里新开的连接依然显示default组。原因通常有两个：一是ALTER RESOURCE GOVERNOR RECONFIGURE只执行了RECONFIGURE没带上ALTER ... WITH (CLASSIFIER_FUNCTION = ...)，函数根本没挂上去；二是函数建在了错误的数据库里——分类器函数必须建在 master 库，建在业务库里挂载时会报错或者被忽略。

解决方式是按顺序重新走一遍：

-- 确认函数是否真的挂在配置上，funcid 为 0 说明没挂 SELECT classifier_function_id, is_enabled FROM sys.dm_resource_governor_configuration; -- 重新挂载并生效（函数必须位于 master 库） USE master; GO ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = dbo.fn_rg_classifier); GO ALTER RESOURCE GOVERNOR RECONFIGURE; GO

classifier_function_id为 0 就是没挂上，为 1 以上才说明函数已注册。改完之后必须新开一个连接验证，老连接不会重新走分类流程。

5.2 现象：内存百分比调了，缓冲池一点没变

把报表池的MAX_MEMORY_PERCENT从 50 压到 20，等了半天，sys.dm_os_buffer_descriptors里这个库的缓存页数量纹丝不动。原因是资源调控器管的是查询执行内存授予，不是缓冲池页面。这个参数只影响排序、哈希这类算子的工作区内存，对数据页缓存没有直接约束。

要限制缓冲池占用只能走别的路：给实例设一个合理的max server memory，把操作系统和其他进程的空间留出来；再针对性地优化大表扫描，减少缓存污染。至于「某个库不准缓存超过多少数据页」，2008 R2 这一代没有直接手段，别在这个参数上白费时间。

5.3 现象：池最大值设了 30%，监控里照样冲到 100%

MAX_CPU_PERCENT设成 30，PerfMon 里这个池的 CPU 使用率曲线依然有尖峰顶到 90% 以上。这不是配置失效，而是软上限的固有行为——调节按调度周期做，短时间的冲高属于正常范围，原文里也明确写了这一点。真正该关注的是持续的平均值，而不是瞬时峰值。

判断上限有没有真的生效，看total_cpu_violation_sec的增长速度比看瞬时曲线靠谱得多。这个值在稳定增长，说明资源调控器确实在压制这个池；如果长时间不变而瞬时曲线又频繁顶满，那多半是这个池根本没跟别人抢资源，上限自然不会触发。另外还有一种情况是实例上只有这一个池在跑业务，其他池全空，那所有资源本来就归它用，最大值的存在感很低。

5.4 现象：连接池把分类结果固化了

应用侧调整了连接字符串里的Application Name，期望流量切到报表组，结果 DMV 里依然是旧的分组。原因是连接池：连接一旦建立就一直被复用，分类器函数在连接建立时执行的那一次结果被连接池原样带下去，只要连接不断开，测试几个月都不会变。

处理方式是让应用侧重启连接池，或者在连接字符串上做一次变更触发连接池重建。验证时用sys.dm_exec_sessions里的connect_time字段排一下，看会话的建立时间是不是在配置修改之后。这个坑在灰度切换流量的时候特别容易踩，切了一半发现新流量进了新组、老流量还在老组，两边配额对不上，压测数据全乱。

5.5 现象：加了分类器函数，登录变慢

上线之后应用侧反馈建立连接的时间从几毫秒涨到几十毫秒，高峰期更明显。排查下来是分类器函数里写了SELECT去查一张配置表，每条新连接都要读一次，那张表上还有别的作业在更新，读操作排队。

解决方式是把函数改回纯字符串判断，所有分流规则硬编码在函数体里或者通过APP_NAME()这类上下文函数取值。配置信息需要变更时，改函数本身再RECONFIGURE，不要在分类阶段做任何数据库访问。这条经验值得记牢：分类器函数是整个实例的登录必经之路，它的执行成本会被所有新连接乘以一遍。

注意：修改分类器函数之前，先在测试实例上量一遍新连接的建立耗时。生产环境的登录延迟不像查询延迟那么容易归因，等应用侧报障再回滚，成本高得多。

6. 进阶：把配置钉死在一组可复现的数字上

配置写完不等于落地完成，隔两周再看，很可能已经悄悄跑偏了。我习惯在改完之后立刻建一套验证闭环：先用 DMV 抓一份基准快照，再用一段可控的压测把某个池推到上限，看它是否真的被限制住，最后把快照存档，后面每次变更都拿来对比。

压测不需要什么工具，开一个会话连进去，跑一段故意吃 CPU 的循环查询就够了。关键是压测的连接必须能让分类器识别成目标组——用报表账号连，或者连接字符串里带上Application Name。压的时候同时在另一个窗口盯池的计数器：

-- 压测过程中反复执行，观察目标池的 CPU 用量与违规秒数是否同步上涨 SELECT p.name, rg.total_cpu_usage_ms, rg.total_cpu_violation_sec, rg.active_memory_grant_count FROM sys.dm_resource_governor_resource_pools AS p JOIN sys.dm_resource_governor_resource_pool_volumes AS rg ON p.pool_id = rg.pool_id WHERE p.name = 'pool_report';

total_cpu_usage_ms是累计 CPU 毫秒数，两次采样之间做差再除以采样间隔，就是这段时间的实际 CPU 占用率。total_cpu_violation_sec开始增长，说明上限开始起作用了。如果压了半天这个值一直是 0，要么上限设得比实际需求高、根本没触到，要么分类器没把压测连接分到目标池——回头查 4.3 那张会话归属表。

几个字段的含义整理一下，方便日常巡检对照：

字段	所属视图	判读方式
total_cpu_usage_ms	sys.dm_resource_governor_resource_pool_volumes	两次采样做差÷间隔，得到实际 CPU 占用率
total_cpu_violation_sec	同上	持续增长说明上限在压制，长期为 0 说明上限形同虚设
active_memory_grant_count	同上	持续高位配合应用超时，说明池内存配额不足
total_memory_grant_count	同上	累计授予次数，用来估算这个池的内存请求频率
group_id	sys.dm_exec_sessions	验证分类结果是否落到预期组

压测之后记得把REQUEST_MAX_MEMORY_GRANT_PERCENT和GROUP_MAX_REQUESTS这两个值回看一遍。压测时的高并发很容易把组的并发上限顶到，这时候应用侧看到的是排队而不是报错，现象很隐蔽——连接看着还在，查询就是不出结果。我第一次做这套配置的时候，报表组并发上限设了 5，压测跑得挺好看，上线后业务方说报表页面转圈转到超时，查了两天才发现是GROUP_MAX_REQUESTS卡住了，组里的请求在排队，DMV 上active_memory_grant_count一切正常，因为请求压根还没到申请内存那一步。从那以后我每次配完资源池，都会单独确认一遍组级并发上限和实际应用的连接池大小是否匹配，再把这份数字写进变更记录里，谁改的、改之前是多少、压测数据如何，一条不落。希望帮到你。

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