有很多文章（见Slava Oks 的原始 SQL 2000 文章和Kevin Kline 的 SQL 2005 更新）建议在 SQL 服务器上禁用超线程，或者至少测试您的特定工作负载在您的服务器上启用它之前。
随着真正的多核处理器取代超线程处理器，这个问题逐渐变得不那么重要了，但目前对这个问题的看法是什么？这个建议对 SQL 2005 64 位、SQL 2008 或 Windows Server 2008 有任何改变吗？
理想情况下，应该在临时环境中提前测试这一点，但对于已启用 HT 投入生产的服务器，该怎么办？我如何判断我们遇到的性能问题是否与 HT 有关？是否有一些特定的性能计数器组合可以指引我朝这个方向发展，而不是我在改进 SQL 性能时通常追求的所有其他事情？
编辑：这尤其具有吸引力，因为有可能全面一些高 CPU 服务器的性能有所改善，但客户希望看到一些具体的东西，帮助我确定哪些服务器真正可以从禁用超线程中受益。当然，传统的性能故障排除仍在进行中，但有时一点点帮助都会有帮助。
答案1
在 SQLOS 中，为 SQL Server 看到的每个逻辑处理器创建一个调度程序。启用超线程后，这相当于将调度程序数量翻倍。SQLOS 的目的之一是尽量减少并防止发生上下文切换，这就是为什么只为每个逻辑处理器创建一个调度程序的原因。一旦 SQLOS 创建了调度程序，总工作程序数量就会在调度程序之间分配。SQLOS 实现了一种协作调度形式，即当调度程序需要不可用的资源或达到其执行量时，工作程序会放弃调度程序，从而允许其他工作程序在调度程序上执行。由于调度程序正在执行工作并且它们是一对一绑定的，因此这使上下文切换保持在最低限度。
了解了这一背景，就会发现超线程在某种程度上与 SQLOS 专门设计的功能相反。具体来说，并行性在超线程中可能会出现问题，并且可能导致高 CXPACKET 等待时间，因为 SQLOS 可能会尝试在 DOP 8 上运行查询，而实际上系统上的 DOP 为 4。如果您的 CPU 利用率很低，您可能不会注意到，但 CPU 利用率越高，问题就越严重。我最近在 Twitter 上就此进行了讨论，大家的共识是“这取决于”它是否有帮助或有害。
如果您的服务器上有大量信号等待，但 CPU 利用率较低，则启用超线程可能会带来好处，这将使您的内部调度程序增加一倍，并将工作程序分散开来，这意味着它们不会在可运行队列中等待执行太长时间。但是，如果您的工作负载大量使用并行性，您会在 sys.dm_os_wait_stats 中看到大量的 CXPACKET 等待，您可以考虑禁用超线程，看看它是否能减少您的等待时间。
答案2
其实超线程并没有消失，英特尔的新款 Nehalem 四核芯片就具有超线程。至于是否推荐，一如既往地“视情况而定”，每种情况可能都不同。
HT 不太可能是任何性能问题的根本原因，但如果没有更多细节，很难说清楚问题出在哪里。进行一些 perfmon 会话，采样率要相当长，比如每 30 - 60 秒一次，获取 CPU、数据和日志磁盘上的磁盘队列长度、页面预期寿命，这是衡量您是否有足够的内存的一个很好的指标。如果您的 CPU 使用率持续超过 80%，或者您的磁盘队列达到三位数，那么您就找到了问题所在。
答案3
HP DL360 G3 上的 SQL Server 2000：
我运行了六次报告，并丢弃了最初的运行，记录了最后五次。然后我再次重新启动数据库并重新打开超线程。我又运行了六次报告，保留了最后五次运行的数据。
观察结果：
- 关闭超线程不会使 CPU 使用率明显增加 2 倍，只会增加 1.5 倍左右。
- 关闭超线程可使随机长时间运行的报告运行速度提高 5.2%（平均）。
重复运行报告：
使用超线程：20.95%、21.1%、21.9%、20.8%、20.5% 运行时间（毫秒）：20282、21141、20188、22297、25282。平均 21838 未使用超线程：29.4%、28.2%、29.1%、28.2%、27.1% 运行时间（毫秒）：20125、20156、19937、21656、21656。平均 20706