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