在SSRS Report Builder中查找的性能影响

我最近遇到了瓶颈情况，如果我在报表内部保留当前版本的查询（在报表生成器SSRS 2008中设计），它将生成最多15次的加载时间具有特定参数的报告的分钟数。此JOIN表示我加入到非索引列的主查询的子查询。我们称这个子查询为“单位”。在SSRS Report Builder中查找的性能影响

如果我删除了“单位”从SQL查询中的连接，并将其设置为一个单独的数据集的报告里面，使用SSRS查找功能（同SQL的JOIN）将它链接到主数据设置（查询），报告运行平稳，不到一分钟（约3至5毫秒）。

请记住，当单独运行时，对于之前花费15分钟的相同参数运行的子查询分别运行时间不到5毫秒，但当它连接到主查询时会导致严重的性能问题。

做这种类型的分离有明显的好处，还是应该进一步调查如何改进查询？使用查找与提高当前查询性能的性能优势/缺点是什么？

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

谢谢，拉杜。

来源

2017-10-17 Radu N.

有很多事情可能会导致性能问题，但这里有一些简单的事情可能使数据集以极小的努力重新加速。

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

这种方法是我经常带它可以避开正是这些类型的性能问题。

来源

2017-10-17 21:33:16

感谢Alan，我试着将数据放入一个临时表中，它与在报告生成器（Lookup函数）中使用解决方法具有相同的效果。我在过去尝试过这种方法，但它没有返回所需的时间，所以我认为它比Lookup函数更不受欢迎。 –

在SSRS Report Builder中查找的性能影响

回答

相关问题