在我的一个数据库中，我已经创建了工作文件/秒性能计数器，失控率平均在10K到20K之间。
有没有人知道如何找出导致此问题的查询？
答案 0 :(得分：3)
当你看到创建大量工作文件/秒时，SQL Server文档在完全描述这里发生的事情方面可悲。
但是，他们确实提供了一些见解： http://msdn.microsoft.com/en-us/library/ms177426.aspx
首先，他们指出创建工作文件（而不是工作表）来存储HASH连接和散列聚合 - 由于尝试加入/组合/聚合大量行/的操作，散列通常会进行结果在方程式的两侧（比较，比较嵌套循环或其他连接/操作）。有关不同JOIN类型的更多信息，请参阅此内容（并记住并非所有散列=连接）： http://msdn.microsoft.com/en-us/library/ms191426%28v=SQL.100%29.aspx
因此。翻译：你看到大量工作文件的原因是因为你的工作量一次又一次地将一个表（或一组JOIN）的大量结果与另一个表（或一组JOIN）进行“混合”。
在多租户系统中，通常会看到创建的高工作文件数/秒（即，高于大多数调优大师为SINGLE数据库推荐的＆lt; 20的典型范围）。但你报道的数字显然非常高。
那说： - 如果你没有遇到其他问题（用户威胁要杀死你，减慢页面加载等），那么（如果你有大量的RAM）这可能不是一个大问题。相反，它可能只是一种“潜伏”的问题，服务器处理得很好，但这会阻碍你的扩展能力。 - 修复或纠正此问题的唯一方法是查看代码和操作。如果你在单个/巨大的切片+骰子查询中组合大量行，这些查询尝试对大量数据执行JOIN +聚合的GOB，那么将这些单个查询分解为多个较小的“子查询”和“预先”过滤'可以/将减少正在创建的工作文件的数量并且将对整体性能和吞吐量产生明显的影响（即，您应该看到在许多情况下，查询的重写可以/将会更快）。
我在这里写过关于'预过滤'的概念： http://devproconnections.com/database-development/generating-high-performance-sql-server-query-results