Question

我最近遇到了瓶颈情况，如果我在报告中保留当前版本的查询（在Report Builder SSRS 2008中设计），它将为特定报告生成最多15分钟的加载时间参数。此JOIN表示我在非索引列上加入主查询的子查询。我们将此子查询称为＆＃34; 单位＆＃34;。

如果我删除＆＃34; 单位＆＃34;从SQL查询加入并在报表中将其设置为单独的数据集，使用SSRS查找功能（与SQL中的JOIN相同）将其链接到主数据集（查询），报表运行顺畅，在下面分钟（大约3到5毫秒）。

请记住＆＃34; 单位＆＃34;子查询，当单独运行时，在5毫秒内运行以前需要15分钟的相同参数，但是当它附加到主查询时会导致严重的性能问题。

进行此类分离是否有明显的好处，还是我应该进一步调查如何改进查询？使用查找与改进当前查询性能的性能优势/缺点是什么？

我担心的是这是一种情境改善，这不代表长期解决方案。我过去曾使用过这种方法来避免调整查询，但这并没有适得其反，但我并不完全理解使用此解决方法的性能影响。

谢谢，拉杜。

Answer 1

有很多事情可能会导致性能问题，但这里有一些简单的事情可能会让数据集重新加速，而且只需很少的努力。

<强> 1。参数嗅探

你提到带有特定参数的，如果你的意思是查询只对一些参数表现不好并且与其他参数表现良好，并且假设数据的大小没有根据这些显着变化参数然后它可能是一个参数嗅探问题。这是由基于一组不适合其他参数的参数生成的查询计划引起的。证明这一点的最简单方法是简单地将option (recompile)添加到查询的末尾。这不是永久修复，但它会强制生成新的查询计划。如果你看到即时改进，那么参数嗅探是最常见的原因。

<强> 2。重构数据集查询

另一种选择是重新设计您的查询。我不知道您的查询是什么样的，但如果我们根据您发布的信息采用一个简单的示例...

如果您查询的内容类似于..

SELECT * FROM tableA a
    JOIN (SELECT * FROM tableB WHERE someValue=someOtherValue) b
        ON a.FieldA = b.FieldB

那么你可以通过将子查询放入临时表并加入其中来重构它，比如

SELECT * 
    INTO #t
    FROM tableB WHERE someValue=someOtherValue

SELECT * FROM tableA a
    JOIN #t b
        ON a.FieldA = b.FieldB

这是我经常采用的一种方法，它可以完全解决这些类型的性能问题。

Lookup在SSRS报表生成器中的性能影响

1 个答案: