我们在SQL Server性能方面遇到了一些困难，需要一些帮助。
我们的环境是： -
Windows 2003 Enterprise x64 Edition R2 英特尔E5450四核3ghz处理器 16GB RAM SQL Server 2005 64位企业版（9.00.3282.00） 数据库兼容性为8（但也在9上进行了测试） 超线程已关闭
我们有一个数据库，其中有一个120万行表正在被查询（效率低下），但导致所有4个处理器都饱和到所有其他查询被阻塞的程度，直到查询完成。这包括对单独的数据库和完全不相关的表的查询。
如果使用选项MAXDOP 1运行查询，则所有4个核心以25％运行，查询时间为4倍，此实例中没有阻塞。除此之外，我们在SQL 2000上运行相同的查询，响应时间相同，但没有CPU饱和。
我们怀疑问题可能是围绕tempdb的争用。在这个特定的实例中，我们有一个使用临时表的存储过程，以及访问我认为的临时数据库的并行查询。
显然，标准响应将是重写查询。首先，这不是一个真正可行的选择，其次这只是治疗问题的症状。本质上，服务器无法处理多个请求，这是非常值得关注的。
是否有人知道可能导致此问题的任何补丁，配置更改或已知问题？谁看过这个吗？它是64位的细微差别吗？
此致
利
答案 0 :(得分：1)
听起来表格没有正确编入索引。具有120万行的表不应该进行任何查询。我有超过60万行的表，我在几毫秒内查询该表。
查询是什么样的，表格看起来像什么？
答案 1 :(得分：0)
听起来像锁定tempdb，它有效地阻止了任何可能使用tempdb运行的东西，直到它完成。特别是可能是sysobjects表被锁定了。
理想的一步是重新编写查询以阻止它在整个持续时间内锁定tempdb，但是，我猜这是不可能的。
您可以尝试设置第二个SQL实例来运行此数据库。这样，任何临时锁定只会影响自身，而不会影响服务器上的任何其他数据库。
要修复在同一数据库上运行的其他查询的问题，您可以查看临时数据库的多个文件。
然而，一旦你为解决方案走到这一步，你真的需要回到问题查询并尝试使其足迹更小。正如Kristen评论的那样，只是改变创建临时表的方式会对锁定事物的方式产生重大影响。