那里有很多文章（参见Slava Oks的原始SQL 2000文章和Kevin Kline的SQL 2005更新 ）build议在SQL服务器上禁用超线程，或者至less在启用服务器之前testing您的特定工作负载 。
随着真正的多核处理器取代超线程处理器，这个问题逐渐变得不那么重要了，但是目前这个问题上的智慧是什么呢？ 这个build议是否会改变SQL 2005 64位或SQL 2008或Windows Server 2008？
理想情况下，应该在临时环境中事先对其进行testing，但对于已启用HT的服务器已经投入生产，该怎么办？ 如何判断我们遇到的性能问题是否与HT有关？ 有没有一些perfmon计数器的特定组合可能指向我的方向，而不是我通常追求改善SQL性能的所有其他事情？
编辑 ：这是特别有吸引力的，因为我的一些高CPU服务器的全面改善的潜力，但客户将希望看到具体的东西，帮助我确定哪些服务器真的可以从禁用超线程获益。 当然，传统的性能故障排除正在进行，但有时候有一点帮助。
在SQLOS中，为SQL Server看到的每个逻辑处理器创build一个调度器。 在启用超线程的情况下，这相当于将调度程序加倍。 SQLOS的目的之一是最小化和防止发生上下文切换，这就是为什么每个逻辑处理器只创build一个调度器。 一旦SQLOS创build调度程序，工作人员总数将在调度程序中分配。 SQLOS实现了一种协作式调度的forms，因为工作人员产生调度器，因为它需要不可用的资源，或达到执行量，允许其他工作人员在调度器上执行。 由于调度程序正在完成这项工作，所以将上下文切换保持在最低限度，并且它们是一对一的。
了解这种背景，超线程有点与SQLOS专门devise的function相反。 具体而言，并行性可能是超线程的问题，并且可能导致CXPACKET高等待，因为SQLOS可能试图在DOP 8上运行关于DOP 4系统的实际情况的查询。 如果您的CPU利用率很低，您可能不会注意到，但CPU利用率越高，问题就越严重。 最近我在twitter上就这个问题进行了一次讨论，共识是“取决于”它是否会帮助或者伤害。
如果您的服务器上有很多信号等待，但是CPU利用率很低，那么您可能会看到启用超线程的好处，这将使您的内部调度程序翻倍，并将工作人员分散到更多位置，这意味着他们不会等待在可运行队列中执行只要。 但是，如果您的工作负载大量使用并行性，则会在sys.dm_os_wait_stats中等待大量的CXPACKET，您可以查看禁用超线程以查看是否减less了等待时间。
事实上，超线程并没有消失，英特尔新的Nehalem四核芯片已经超线程。 至于是否推荐，“一切依赖”，每种情况都可能有所不同。
HT不太可能是任何性能问题的根本原因，但没有更多的细节，很难说什么是。 以相当长的采样率进行一些perfmon会话，比如每30-60秒一次，并在数据和日志磁盘上获得cpu，磁盘队列长度，页面预期寿命是衡量内存是否足够的一个很好的衡量标准。 如果你的CPU一直超过80％，或者你的磁盘队列在三位数字上，你发现你的问题。
HP DL360 G3上的SQL Server 2000：
我跑了六次报告，最初跑掉了，logging了最后五次。 然后，我重新启动了数据库，并重新启用了超线程。 我再次运行了六次报告，保留了最近五次运行的数据。
观察：
报告重复运行：
超线程：20.95％，21.1％，21.9％，20.8％，20.5％ 以ms为单位的运行时间：20282，21141，20188，22297，25282。平均值21838 没有超线程：29.4％，28.2％，29.1％，28.2％，27.1％ 在ms中运行时间：20125，20156，19937，21656，21656。平均值20706