嗨伙计，
我有一个SQL Server 2005系统，有4个CPU，每个都有4个内核。 目前主要利用4个核心，即4个徘徊在90％左右的利用率和其他接近30％。 我假设4个核心是一个来自每个CPU，虽然我不确定。 这是预期的行为有没有人知道？ 将增加的负载分配到额外的核心，而不是进一步加载到目前4.这是否表明我应该调查的其他问题？
在峰值负载情况下，我预计至less同时有超过40个连接，并且大多数（如果不是全部的话）将被设置为允许脏读取。 由于这个原因，我不认为这与工作负载到达SQL Server有什么关系，而是它如何select使用它可用的CPU资源。
谢谢，
知更鸟
根据最大并行度和并行度成本阈值，SQL会根据sp_configure的高级选项自动pipe理CPU使用情况（请参阅联机丛书）。
您可能需要查看这些设置，并可能自己查看SQL脚本。
SQL没有办法pipe理物理内核的线程分配。 这是一个特权只有操作系统了。 SQL不强制使用亲和性掩码（缺less全局可configurationSQL宽亲和性掩码来限制SQL看到的CPU数量）。 你看到的行为最终是由主板驱动程序，CPU驱动程序和核心操作系统驱动的。 我看到了与multithreading相关的类似行为或与驱动程序问题相关的行为。
理想的行为是让所有内核共享相同的CPU负载，也许由于处理某些硬件中断（networking），可能会有更多的内核负载（红线）。
当然，我认为你的SQL负载可以跨CPU传播出去，有一些非常不寻常的负载，比如有非常less的请求，但是在计算中非常激烈，但是，在SQL语境中又是非常不寻常的。