blocks|key|2696072|text|额外的时间可能是因为除了查询数据之外，Reporting+Services还会呈现报表。例如，如果您为报表返回了55,000行，而报表服务器必须对这些行进行分组、排序和/或筛选才能呈现报表，则这可能需要额外的时间。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2696073|我将查看一下在报告中对数据进行分组和筛选的方式，然后查看您的存储过程，看看是否可以将某些处理工作转移到SQL代码中，也许可以使用一些参数。尽量将返回到报表的行数减少到呈现报表所需的最小行数，最好避免在报表本身中进行分组和筛选。|2696074|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The additional time could be due to Reporting Services rendering the report in addition to querying the data. For example if you have 55,000 rows returned for the report and the report server then has to group, sort and/or filter those rows to render the report then that could take additional time.

I would have a look at the way the data is being grouped and filtered in the report, then review your stored procedure to see if you could offload some of that processing to the SQL code, maybe using some parameters. Try and aim to reduce the the amount of rows returned to the report to be the minimum needed to render the report and preferably try to avoid doing the grouping and filtering in the report itself.

blocks|key|2696163|text|我有这样的问题，因为我的SP中的参数嗅探。在SQL+Management+Studio中，当我运行我的SP时，我用新的执行计划重新创建了它(并且调用非常快)，但是我的报告使用了旧的坏计划(对于另一个参数序列)，并且加载时间比在SQL+MS.中要长得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2696164|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I had such problem because of parameters sniffing in my SP. In SQL Management Studio when I run my SP, I recreated it with new execution plan (and call was very fast), but my reports used old bad plan (for another sequence of parameters) and load time was much longer than in SQL MS.

blocks|key|2696090|text|在ReportServerDB中，您将找到一个名为ExecutionLog的表。您必须查找报告的目录id，并检查最新的执行实例。这可以告诉你所用时间的分解--数据检索，处理，渲染等。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2696091|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

in the ReportServerDB you will find a table called ExecutionLog. you got to look up the catalog id of your report and check the latest execution instance. this can tell you the break-up of the times taken - for data retrieval, for processing, for rendering etc.

blocks|key|1963627|text|使用SSRS+Performance+Dashboard报告来调试您的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1963628|entityMap|0|LINK|mutability|MUTABLE|url|http://sqlconcept.com/tools/ssrs-performance-dashboard/^0|2|Q|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Use the <a href="http://sqlconcept.com/tools/ssrs-performance-dashboard/" rel="nofollow">SSRS Performance Dashboard</a> reports to debug your issues.

blocks|key|2696478|text|这是一个老生常谈的问题，但因为这样的事情是反复发生的，我的改进SSRS的“又快又脏”的解决方案是正确设置页面的InteractiveSize+(例如，将其设置为A4+-21+cm+)。SSRS可以在大型企业环境中完美地工作(我正在呈现每天最多有100.000%2B行的报表)。当InteractiveSize设置为0时，所有结果都将呈现为单页面，这实际上会扼杀SSRS的性能。在这样的情况下，在数据库上花费几秒钟的查询可能永远不会呈现(或者导致内存不足异常，除非您的SSRS服务器上有大量冗余的硬件)。因此，在查询/SP在直接调用和检索大量行时执行得相当快的情况下，设置InteractiveSize，您就不需要使用其他更复杂的解决方案了。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2696479|entityMap^0|1J|F|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

Archaic question but because things like that are kinda recurring, my "quick and dirty" solution to improve SSRS, which works perfectly on large enterprise environments (I am rendering reports that can have up to 100.000+ lines daily) is to properly set the InteractiveSize of the page (for example, setting it to A4 size -21 cm ). When InteractiveSize is set to 0, then all results are going to be rendered as single page and this literally kills the performance of SSRS. In cases like that, queries that can take a few seconds on your DB can take forever to render (or cause an out of memory exception unless you have tons of redundant H/W on your SSRS server). 
So, in cases of queries/ SP's that execute reasonably fast on direct call and retrieve large number of rows, set InteractiveSize and you won't need to bother with other, more sophisticated solutions.

blocks|key|4809525|text|我遇到了一个类似的问题:在SSRS中，一个返回4,000行并在1秒内运行的查询耗时太长，以至于超时。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4809526|事实证明，这个问题是由SSRS处理多值参数的方式引起的。有趣的是，如果用户选择了多个值，报表的呈现速度会很快(~1秒)，但如果只选择了一个值，则需要几分钟的时间才能呈现报表。|4809527|下面是原始查询，它的渲染时间超过了正常时间的100倍：|4809528|SELECT+...
FROM+++...
WHERE++filename+IN+(@file);
--+@file+is+an+SSRS+multi-value+parameter+passed+directly+to+the+query|code-block|syntax|javascript|4809529|我怀疑问题是SSRS引入了整个源表(超过100万行)，然后执行客户端过滤。|4809530|为了解决这个问题，我最终通过表达式将参数传递给查询，这样我就可以自己控制过滤器。也就是说，在"DataSet属性“窗口的”参数“屏幕上，我用以下表达式替换了参数值：|4809531|=JOIN(Parameters!file.Value,",")|4809532|..。(我还给结果起了一个新的名字:+filelist)，然后我更新了查询，如下所示：|4809533|SELECT+...
FROM+++...
WHERE++','+%2B+@filelist+%2B+','+LIKE+'%25,'+%2B+FILENAME+%2B+',%25';
--+@filelist+is+passed+to+the+query+as+the+following+expression:
--+=JOIN(Parameters!file.Value,",")|4809534|我猜将查询移动到存储过程也是缓解问题的有效方法(因为SSRS基本上在将多值参数传递给存储过程之前执行相同的连接)。但在我的例子中，在报告中处理这一切要简单得多。|4809535|最后，我应该指出的是，LIKE操作符可能不是过滤项目列表的最有效方法，但它的编码肯定比拆分字符串方法简单得多，而且报告现在大约在一秒钟内运行，因此拆分字符串似乎不值得付出额外的努力。|4809536|entityMap^0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|12|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|13|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|14|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|15|8|@]|9|@]|A|$]]|$1|O|3|P|5|H|7|16|8|@]|9|@]|A|$I|J]]|$1|Q|3|R|5|6|7|17|8|@]|9|@]|A|$]]|$1|S|3|T|5|H|7|18|8|@]|9|@]|A|$I|J]]|$1|U|3|V|5|6|7|19|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1B|8|@]|9|@]|A|$]]]|Z|$]]

I had a similar problem: a query that returns 4,000 rows and runs in 1 second on it's own was taking so long in SSRS that it timed out.

It turned out that the issue was caused by the way SSRS was handling a multi-valued parameter. Interestingly, if the user selected multiple values, the report rendered quickly (~1 second), but if only a single value was selected, the report took several minutes to render.

Here is the original query that was taking more than 100x longer to render than it should:

<pre><code>SELECT ...
FROM ...
WHERE filename IN (@file);
-- @file is an SSRS multi-value parameter passed directly to the query
</code></pre>

I suspect the issue was that SSRS was bringing in the entire source table (over 1 million rows) and then performing a client-side filter.

To fix this, I ended up passing the parameter into the query through an expression, so that I could control the filter myself. That is, in the "DataSet Properties" window, on the "Parameters" screen, I replaced the parameter value with this expression:

<pre><code>=JOIN(Parameters!file.Value,",")
</code></pre>

... (I also gave the result a new name: filelist) and then I updated the query to look like this:

<pre><code>SELECT ...
FROM ...
WHERE ',' + @filelist + ',' LIKE '%,' + FILENAME + ',%';
-- @filelist is passed to the query as the following expression:
-- =JOIN(Parameters!file.Value,",")
</code></pre>

I would guess that moving the query to a stored procedure would also be an effective way to alleviate the problem (because SSRS basically does the same JOIN before passing a multi-value parameter to a stored procedure). But in my case it was a little simpler to handle it all within the report.

Finally, I should note that the LIKE operator is maybe not the most efficient way to filter on a list of items, but it's certainly much simpler to code than a split-string approach, and the report now runs in about a second, so splitting the string didn't seem worth the extra effort.

blocks|key|58042|text|显然，让报告正确运行(即，花费与SSMS相同的时间来选择数据)会更好，但作为一种变通方法，您的报告是否支持执行快照(即，没有参数或报告中存储的参数默认值)？|type|unstyled|depth|inlineStyleRanges|entityRanges|data|58043|这将允许预先检索和存储数据的计划快照，这意味着SSRS只需要在用户打开报表时对其进行处理和呈现。应将等待时间减少到几秒钟(取决于处理报告所需的内容)。YMMV，测试一下您是否获得了性能提升)。|58044|转到报表管理器中的报表属性选项卡，依次选择“执行”、“更改”以从报表执行快照呈现此报表，然后指定您的计划。|58045|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Obviously getting the report running correctly (i.e. taking the same order of magnitude of time to select the data as SSMS) would be preferable but as a work around, would your report support execution snapshots (i.e. no parameters, or parameter defaults stored in the report)?

This will allow a scheduled snapshot of the data to be retrieved and stored beforehand, meaning SSRS only needs to process and render the report when the user opens it. Should reduce the wait down to a few seconds (depending on what processing the report requires. YMMV, test to see if you get a performance improvement). 

Go to the report's properties tab in Report manager, select Execution, change to Render this report from a report execution snapshot, specify your schedule.

blocks|key|57497|text|提高SSRS报告速度的主要解决方案是对报告进行高速缓存()。如果用户这样做(例如，我在上午7:30预加载缓存)或缓存命中时的报告，则会发现加载速度有很大提高。|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|57498|请注意，我每天都这样做，而且是专业的，而不是简单地在SSRS上为诗意打蜡|57499|SSRS+http://msdn.microsoft.com/en-us/library/ms155927.aspx中的缓存|57500|预加载缓存http://msdn.microsoft.com/en-us/library/ms155876.aspx|57501|如果您不喜欢初始报告花费很长时间，并且您的数据是静态的，即每日总账或类似数据，这意味着数据在一天中相对静态，您可以增加缓存寿命。|57502|最终，您也可以选择让业务经理通过电子邮件订阅接收这些报告，这将向他们发送一个时间点报告，他们可能会发现更容易和更系统化。|57503|您还可以使用SSRS中的参数，以方便用户进行解析和更快的查询。在您想要参数化的Filter列下的查询构建器中键入IN(@SSN)，然后您会发现它是在BIDS+GUI左上角数据源上方的参数文件夹中创建的。[如果您在SSRS中看不到数据源部分，请点击CTRL%2BALT%2BD。|57504|在这里可以看到一个几乎相同的问题：Performance+Issuses+with+SSRS|57505|entityMap|0|LINK|mutability|MUTABLE|url|http://msdn.microsoft.com/en-us/library/ms155927.aspx|1|http://msdn.microsoft.com/en-us/library/ms155876.aspx|2|https://stackoverflow.com/questions/976133/performance-issuses-with-ssrs/11229634#11229634^0|1U|D|0|0|5|1H|0|0|5|1H|1|0|1I|9|0|0|2|G|6|15|J|0|0|3Q|0|0|1A|H|T|2|0^^$0|@$1|2|3|4|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|18|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|19|8|@]|D|@$9|1A|A|1B|1|1C]]|E|$]]|$1|J|3|K|5|6|7|1D|8|@]|D|@$9|1E|A|1F|1|1G]]|E|$]]|$1|L|3|M|5|6|7|1H|8|@$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1K|8|@$9|1L|A|1M|B|C]|$9|1N|A|1O|B|C]|$9|1P|A|1Q|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1R|8|@$9|1S|A|1T|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|D|@$9|1X|A|1Y|1|1Z]]|E|$]]|$1|T|3|-4|5|6|7|20|8|@]|D|@]|E|$]]]|U|$V|$5|W|X|Y|E|$Z|10]]|11|$5|W|X|Y|E|$Z|12]]|13|$5|W|X|Y|E|$Z|14]]]]

The primary solution to speeding SSRS reports is to cache the reports. If one does this (either my preloading the cache at 7:30 am for instance) or caches the reports on-hit, one will find massive gains in load speed. 

Please note that I do this daily and professionally and am not simply waxing poetic on SSRS

Caching in SSRS
<a href="http://msdn.microsoft.com/en-us/library/ms155927.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/ms155927.aspx</a>

Pre-loading the Cache
<a href="http://msdn.microsoft.com/en-us/library/ms155876.aspx" rel="nofollow noreferrer">http://msdn.microsoft.com/en-us/library/ms155876.aspx</a>

If you do not like initial reports taking long and your data is static i.e. a daily general ledger or the like, meaning the data is relatively static over the day, you may increase the cache life-span. 

Finally, you may also opt for business managers to instead receive these reports via email subscriptions, which will send them a point in time Excel report which they may find easier and more systematic.

You can also use parameters in SSRS to allow for easy parsing by the user and faster queries. In the query builder type IN(@SSN) under the Filter column that you wish to parameterize, you will then find it created in the parameter folder just above data sources in the upper left of your BIDS GUI.
[If you do not see the data source section in SSRS, hit CTRL+ALT+D.

See a nearly identical question here: <a href="https://stackoverflow.com/questions/976133/performance-issuses-with-ssrs/11229634#11229634">Performance Issuses with SSRS</a>

blocks|key|1963686|text|可以执行以下几项操作来提高报告的性能:+1.在报告管理器上启用缓存，并设置刷新缓存的时间段。2.在报表中用作源的所有后端数据库表上应用索引，尽管您的存储过程渲染数据的时间已经非常短，但仍然应用索引可以进一步提高后端级别的性能。3.在报表中使用共享数据集，而不是使用嵌入式数据集，并对所有这些数据集应用缓存。4.如果可能，设置参数以加载默认值。5.尝试减少存储过程选择的数据，例如，如果报告包含无用的历史数据，则可以添加筛选器以排除该数据。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1963687|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Few things can be done to improve the performance of the report which are as below:
1. Enable caching on the report manager and set a time period to refresh the cache.
2. Apply indexing on all the backend database tables that are used as a source in the report, although your stored procedure is already taking very less time in rendering the data but still applying indexing can further improve the performance at the backend level.
3. Use shared datasets instead of using embedded datasets in the report and apply caching on all these datasets as well.
4. If possible, set the parameters to load default values.
5. Try to reduce the data that is selected by the stored procedure, e.g. if the report contains historical data which is of no use, a filter can be added to exclude that data.

blocks|key|58160|text|我也遇到过同样的问题。查询在SQL中运行得很好，但是在SSRS中运行得很慢。您是否在数据集中使用SSRS参数？我发现，如果在某些查询中直接使用report参数，会对性能造成很大的影响。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|58161|相反，如果在数据集中有一个名为@reportParam的报表参数，只需执行以下操作：|58162|declare+@reportParamLocal+int
set+@reportParamLocal+=+@reportParam

select+*+from+Table+A+where+A.field+=+@reportParam|code-block|syntax|javascript|58163|这有点奇怪。我不太清楚为什么它能工作，但它对我来说是有效的。|58164|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I experienced the same issue. Query ran in SQL just fine but was slow as anything in SSRS. Are you using an SSRS parameter in your dataset? I've found that if you use the report parameter directly in certain queries, there is a huge performance hit.

Instead, if you have a report parameter called @reportParam, in the dataset, simply do the following:

<pre><code>declare @reportParamLocal int
set @reportParamLocal = @reportParam

select * from Table A where A.field = @reportParam
</code></pre>

It's a little strange. I don't quite know why it works but it does for me.

blocks|key|58186|text|您可能希望快速查看报表上的元素是否会减慢执行速度。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|58187|例如，我发现在dateTimes之间转换时存在巨大的执行时间差异。报表中有没有使用CDate函数的元素？如果是这样的话，您可能需要考虑在sql级别进行格式化。|58188|转换通常会导致大量的速度减慢，所以请花时间查看您的数据集，看看可能的问题是什么。|58189|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

One quick thing you may want to look at is whether elements on your report could be slowing down the execution. 

For example i have found massive execution time differences when converting between dateTimes. Do any elements on report use the CDate function? If so you may want to consider doing your formatting at the sql level.

Conversions in general can cause a massive slow down so take the time to look into your dataset and see what may be the problem.

blocks|key|2696405|text|这有点混合了上面的答案，但请尽最大努力以最简单和最完整的格式从存储过程中取回数据。我在服务器上进行所有的排序、分组和过滤。服务器就是为此而构建的，我只是让报告服务来做漂亮的显示工作。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2696406|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This is a bit of a mix of the answers above, but do your best to get the data back from your stored procedure in the simplest and most finished format. I do all my sorting, grouping and filtering up on the server. The server is built for this and I just let reporting services do the pretty display work.

blocks|key|1963772|text|我也有同样的问题...这确实是渲染时间，但更具体地说，是因为排序是在SSRS中进行的。尝试将排序移动到存储过程，并从SSRS报告中删除任何排序。在55K行上，这将极大地提高性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1963773|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I had the same issue ... it was indeed the rendering time but more specifically, it was because of the SORT being in SSRS. Try moving your sort to the stored procedure and removing any SORT from the SSRS report. On 55K rows, this will improve it dramatically.

blocks|key|1963806|text|根据@RomanBadiornyi的回答，尝试添加|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1963807|OPTION+(RECOMPILE)|code-block|syntax|javascript|1963808|添加到存储过程中主查询的末尾。|1963809|这将确保每次都为不同的参数重新编译查询，以防不同的参数需要不同的执行计划。|1963810|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Further to @RomanBadiornyi's answer, try adding 

<pre><code>OPTION (RECOMPILE)
</code></pre>

to the end of your main query in the stored procedure.

This will ensure the query is recompiled for different parameters each time, in case different parameters need a different execution plan.

I Have created an SSRS Report for retrieving 55000 records using a Stored Procedure. When 
executing from the Stored Proc it is taking just 3 seconds but when executing from SSRS report it is taking more than one minute. How can I solve this problem?

SSRS Performance

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我已经创建了一个SSRS报告，用于使用存储过程检索55000条记录。当从存储的Proc执行时，它只需要3秒，但当从SSRS报告执行时，它需要一分钟以上。我该如何解决这个问题？

问SSRS性能
EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SSRS性能EN

回答 14

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问SSRS性能
EN