我们有一个包含大约 40 个不同（每个大约 1-5GB）数据库的 SQL 服务器。服务器是一个 8 核 2.3G CPU 和 32G 内存。27Gig 固定到 SQL Server。CPU 利用率几乎总是接近 100%，内存消耗约为 95%。这里的问题是 CPU 一直接近 100% 并试图了解原因。
我已经运行了一个初始检查，以查看哪个数据库通过使用这个脚本导致了高 CPU，但我无法详细证实真正消耗 CPU 的内容。顶部查询（来自所有数据库）只需大约 4 秒即可完成。IO 也不是瓶颈。
记忆会是这里的罪魁祸首吗？我检查了内存拆分，并且 OBJECT CACHE 占用了分配给 SQL Server 的大约 80% 的内存 (27G)。我希望这是正常的，只要涉及到很多 SP。运行分析器，我确实看到了很多重新编译，但主要是由于“临时表更改”、“延迟编译”等，并且不清楚这些重新编译是否是由于内存压力导致计划被抛出缓存的结果
欣赏任何想法。
您可以在 SSMS 中看到一些报告：
右键单击实例名称/报告/标准/顶级会话
您可以看到 CPU 消耗最高的会话。这可能有助于了解哪些 SQL 进程正在使用资源。如果您环顾四周，还有其他一些与 CPU 相关的报告。我打算指出更多的 DMV，但如果你已经研究过，我会跳过它。
您可以使用sp_BlitzCache查找 CPU 消耗最高的查询。您还可以按 IO 和其他内容进行排序。这是使用在重新启动之间累积的 DMV 信息。
这篇文章看起来很有希望。
来自 Ozar 先生的一些stackoverflow优点。
编辑：多一点建议...运行“仅”5 秒的查询可能是个问题。它可能会使用你所有的核心，真正运行 8 个核心乘以 5 秒 - 40 秒的“虚拟”时间。我喜欢使用一些 DMV 来查看该代码执行了多少次，以查看 5 秒加起来的内容。
根据这篇关于 sqlserverstudymaterial 的文章；
请记住，“%Privileged time”不是基于 100%。它基于处理器数量。如果您看到 sqlserver.exe 为 200，并且系统有 8 个 CPU，那么 sqlserver.exe 消耗的 CPU 是 800 中的 200（仅25%）。
如果“% Privileged Time”值超过 30% 则一般是驱动程序或杀毒软件有问题造成的。在这种情况下，请确保 BIOS 和过滤驱动器是最新的，然后尝试暂时禁用防病毒软件以查看更改。
如果“% User Time”很高，则说明 SQL Server 有一些消耗。有几种已知模式可能会导致 SQL Server 中运行的进程的 CPU 过高，包括