SQL Server 2022 的资源调控器不支持为视图配置独立资源策略，因视图无运行时资源消耗、分类器函数无法识别视图调用语义，调控粒度仅限会话或请求；替代方案需依赖会话上下文、应用名或注释等外显标识，并严格完成资源池、工作负载组、绑定分类器及重配置等步骤。
SQL Server 2022 的资源调控器（Resource Governor）不支持直接为视图（VIEW）配置独立的资源池或工作负载组。 视图本身不执行资源消耗行为，它只是存储的 SELECT 语句定义；实际资源占用发生在查询视图的会话执行时。调控必须基于会话上下文（如登录名、应用程序名、主机名）或查询本身的分类逻辑，而非视图对象本身。
为什么不能对视图设置 Resource Governor？
Resource Governor 的分类器函数（Classifier Function）只能检查 SESSION_CONTEXT()、ORIGINAL_LOGIN()、APP_NAME()、HOST_NAME()、PROGRAM_NAME() 等运行时会话属性，无法解析或识别当前正在执行的 SQL 文本中是否引用了某个特定视图。即使你写 SELECT * FROM dbo.MyView，分类器看到的仍是整个批处理文本，不是“调用了 MyView”这个语义事件。
资源调控的粒度是会话（session）或请求（request），不是数据库对象。SQL Server 不在执行计划生成前做“视图展开溯源”，更不会把资源策略绑定到 sys.views 中的某一行记录上。
替代方案：用分类器函数识别调用视图的查询模式
虽然不能锁定视图名，但你可以让应用或调用方主动声明意图，再由分类器函数捕获。常见可行路径：
- 要求客户端在查询前执行
EXEC sp_set_session_context @key = N'view_used', @value = N'dbo.SalesSummary'，然后在分类器函数中读取SESSION_CONTEXT(N'view_used')并路由到对应工作负载组 - 约定所有访问敏感视图的应用统一使用特定
APP_NAME()，例如在连接字符串里加Application Name=ReportingApp，分类器匹配APP_NAME() LIKE '%ReportingApp%' - 对关键报表查询显式加注释，如
/* view: dbo.Customer360 */ SELECT ... FROM dbo.Customer360，再用分类器函数解析@inputbuf（需启用sys.dm_exec_input_buffer权限并注意性能开销）——但此法不稳定，不推荐用于生产
必须启用并验证的配置步骤
即使采用上述替代方案，以下操作缺一不可，否则分类器函数不会生效：
- 确保已创建资源池（
CREATE RESOURCE POOL）和工作负载组（CREATE WORKLOAD GROUP），且工作负载组关联到正确资源池 - 分类器函数必须使用
SCHEMABINDING，返回值类型为sysname，且函数体内不能有副作用（如写表、调用非确定性函数） - 执行
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION = [dbo].[my_classifier])后，必须运行ALTER RESOURCE GOVERNOR RECONFIGURE才真正加载 - 分类器函数被调用时，会话尚未执行任何用户代码，因此不能依赖
CONTEXT_INFO或临时表；唯一可靠的是SESSION_CONTEXT()、登录名、应用名等启动期可得信息
最易被忽略的一点：分类器函数只在每个新会话首次请求资源时执行一次（不是每次查询都调），所以 SESSION_CONTEXT 必须在连接建立后、第一条查询前设置好；如果应用复用连接池，还可能需要在每次查询前重置上下文以适配不同视图场景。
