我们在具有 8 个 vCPU 的 Windows 2022 VM 上安装了 SQL Server 2022 CU13 Enterprise。即使服务器上没有用户生成的负载（这意味着目前没有用户连接，即使 SQL Server 代理已停止以消除所有非系统负载），sqlserver.exe 进程也显示 CPU 利用率高达 10-15% 之间。在空闲时间，主要的等待类型是 SOS_SCHEDULER_YELD。
此服务器活动还会阻止 SQL Server 服务停止。尝试停止服务会导致无休止的等待，并且需要终止 Windows 服务进程以使其“停止”。重新启动后，利用率在一段时间内完全正常（空闲服务器的 CPU 利用率为 */- 0），但在用户负载运行一段时间后（最多几小时或几天），问题再次出现。这意味着利用率高于生成用户负载时的应有水平，并且再次，在负载停止后（没有用户连接），利用率仍然很高，如上所述...
错误日志、XE 健康会话、Windows 事件日志中没有可疑消息……
以下是上述空闲期间服务器上的活动监视器视图：
经过一番调查，我很可能确定了导致这种利用率的 SPID。它似乎是一个系统 SPID（调查时为 SPID 37），并且在 10 秒内消耗了大约 10 秒的 CPU 时间（参见下面查询 4 的输出）。SPID 的 database_id 似乎在 master（database_id = 1）和其中一个用户数据库（database_id = 10）之间变化。只有数据库 id 1 和 10 似乎参与了此 SPID 活动。SPID 还在 tempdb 中生成不断增加的分配（参见下面查询 3 的输出）。
以下是在拍摄上面的活动监视器图片的同时 sys.dm_exec_request 的输出（有问题的 spid 是 37）：
以下是 sp_WhoIsActive 同时的输出：
以下是 10 秒内 SPID 所消耗的 CPU 时间的计算：
据我了解，这似乎是一项 Service Broker 活动。但是，主数据库和用户数据库中均未启用 Service Broker。我们不会主动在数据库中使用 Service Broker。我不知道此代理活动可能是什么，也不知道它可以与哪些系统活动相关联。服务器上或该用户数据库中均未使用任何“不寻常”的功能，只有“基本通用功能集”，唯一的“不寻常功能”是启用了 TDE。
关于如何进一步调查此问题的根本原因（此经纪人活动的目的何在）以及如何摆脱它，您有什么想法吗？
经过几次尝试，我终于找到了上述行为的根本原因。在“有问题的”数据库中启用了查询存储，并且用户生成的负载主要由即席查询组成。这导致查询存储很快被填满，并触发了“基于大小的清理程序”。这种基于大小的清理似乎是 CPU 利用率的根源。
无法“和平地”关闭 SQL Server 服务似乎是由于查询存储正在等待将某些数据刷新到磁盘（这可以通过使用 7745 跟踪标志来避免）造成的。
无论如何，这引发了一个与查询存储行为（损坏的查询存储）相关的新问题