我注意到运行 SQL Server 2008 的 8-CPU 数据库服务器上的 CPU 使用率根本不平衡。
以下是一段时间前某一天的随机 1 天平均值，这是典型且始终不对称的：
9, 15, 10, 21, 18, 21, 14, 9
（这里只有缩略图，因为图像是真的高，但点击即可查看完整尺寸图像）
与我们的 4-CPU Web 服务器相比，它们几乎完全平衡每时每刻，这让我感觉很奇怪。
现在，这是一台专用服务器，因此唯一运行的是 SQL Server 2008（以及我们大量使用的内置全文索引），所以我不确定为什么 CPU 使用率如此不对称. 想法？
答案1
您的文件/文件组是如何设置的？
我会抄袭我：
关于 IO 的另一个想法：我们小心地将我们最常用的最大表设置为包含多个文件的文件组。这样做的一个性能增强是 SQL 将对文件组中的每个文件进行线程请求 - 因此，如果 BigOverUsedTable 在 FileGroup1 上，并且 FileGroup1 中有四个文件，并且您的数据库有 8 个核心，它实际上将使用四个核心来执行“从 BigOverUsedTable 中选择大数字运算讨厌的查询” - 否则，它只会使用一个 CPU。我们从这篇 MSDN 文章中得到了这个想法：
http://msdn.microsoft.com/en-us/library/ms944351.aspx
来自TFA：
“文件组使用并行线程来改善数据访问。当按顺序访问表时，系统会为每个文件并行创建一个单独的线程。当系统对具有四个文件的文件组中的表执行表扫描时，它会使用四个单独的线程并行读取数据。通常，在单独的磁盘上使用多个文件可以提高性能。文件组中的文件太多可能会导致过多的并行线程并造成瓶颈。”
根据这个建议，我们在 8 核机器上的文件组中有四个文件。效果很好。
编辑：现在有另一个（可能）更好的答案。图表偏离了比例 - 如果你仔细观察，你会发现每个处理器的负载实际上约为 20%，正如 uzbones 指出的那样。
编辑：我们实际上可以说使用多个文件文件组是有帮助的，因为我们没有将所有表都放在包含四个文件的文件组中。对“单个文件”文件组执行的大查询仅使用一个 CPU，但对包含四个文件的文件组中的表执行的查询会占用 4 个 CPU。
答案2
它们所有的尺度都不同，除了 4 个图表上的峰值外，您的平均值都约为 10-25%。
答案3
看一下这个：
http://blogs.technet.com/mat_stephen/archive/2005/02/02/365325.aspx
SQL 可能仅写入少数文件并且每个处理器都在使用每个文件。
答案4
因为刷新 CPU 缓存的代价非常高，所以内核会不惜一切代价地避免它。
（注：至少 Linux 是这样的；如果 Windows 没有同样的行为我会很惊讶）