遗憾的是,当您看到每秒创建大量工作文件时,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
所以。翻译:您看到大量工作文件的原因是因为您的工作负载一遍又一遍地将一个表(或一组联接)中的大量结果与另一个表(或一组联接)“混合”。
在多租户系统中,通常会看到每秒创建的工作文件数量很高(即高于大多数调优专家建议的单个数据库的典型范围 < 20)。但你报告的数字显然相当高。
也就是说: - 如果您没有遇到其他问题(用户威胁要杀死您、页面加载缓慢等),那么(如果您有大量 RAM)这可能不是一个大问题。相反,它可能只是服务器处理得很好的一种“潜伏”问题,但这会阻碍您的扩展能力。- 解决或纠正此问题的唯一真正方法是查看您的代码和操作。如果您在单个/巨大的切片+骰子查询中组合大量行,尝试对大量数据进行 JOIN + 聚合的 GOB,那么将这些单个查询分解为多个较小的“子查询”和“预查询” “过滤”可以/将会减少创建的工作文件的数量,并且会对整体性能和吞吐量产生明显的影响(即,您应该看到在许多情况下重写查询可以/将会明显更快)。
我在这里写了关于“预过滤”的概念: http://devproconnections.com/database-development/geneating-high-performance-sql-server-query-results
| 归档时间: |
|
| 查看次数: |
6446 次 |
| 最近记录: |