SSRS 报表生成器中查找的性能影响

Question

我最近遇到了瓶颈情况，如果我将当前版本的查询保留在报表中（在 Report Builder SSRS 2008 中设计），它将为具有特定参数的报表生成长达 15 分钟的加载时间。此 JOIN 表示一个子查询，我将其加入到非索引列上的主查询中。我们将此子查询称为“Units”。

如果我从 SQL 查询中删除“Units”联接并将其设置为报表内的单独数据集，使用 SSRS 查找函数将其链接（与 SQL 中的联接相同）到主数据集（查询），报表运行平稳，不到一分钟（大约 3 到 5 毫秒）。

请记住，“Units”子查询在单独运行时对于之前需要 15 分钟的相同参数在 5 毫秒内运行，但是当它附加到主查询时会导致严重的性能问题。

进行这种类型的分离是否有明显的好处，还是我应该进一步研究如何改进查询？使用查找与提高当前查询性能相比有哪些性能优势/劣势。

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

谢谢， 拉杜。

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

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