SQL Server 中的查询持续时间估计
我在 Oracle 10g 中看到了一个功能,可以估计长时间运行的查询的剩余时间,我想知道这在 SQL Server 中是否也可能(至少在 2008 年?)?
假设我有一个非常大的表,其中有数千万行(索引良好等),并且我需要搜索一些特定的行。 我知道这会花费很多时间,而且我对此很满意,但我想向用户展示某种进度条。
我如何展示进步?
I've seen in Oracle 10g a feature that estimates the remaining time for a long running query and I was wondering if this is possible too in SQL Server (at least in 2008?)?
Suppose I have a very large table with tens of millions of rows (well indexed etc. etc.) and I need to search for some particular rows. I know it will take a lot of time and I'm cool with that but I would like to present the user with some kind of a progress bar.
How can I show progress?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我会忘记它,只是放一个旋转的圆圈!
不过说真的,为了进一步发展 MrTelly 的想法,动态管理视图可以为您提供某些查询的平均执行时间 - 也许这可以让您有所收获。
http://msdn.microsoft.com/en-us/library/ms188754。 aspx
编辑:
我已经看到 Adam Machanic 的 sp_whoisactive 过程完成了百分比。 也许这是另一个值得研究的地方。 SQL 2016 具有保留计划缓存信息的查询存储 - dmv 计划缓存的替代品,该缓存在重新启动时会被清除。
I'd forget about it and just put a spinning circle!
Seriously though, to take MrTelly's idea further, there are dynamic management views that can give you average execution times for certain queries - maybe that can get you somewhere.
http://msdn.microsoft.com/en-us/library/ms188754.aspx
edit:
I have seen percent complete in the sp_whoisactive procedure from Adam Machanic. Maybe that is another place to look into. SQL 2016 has the query store which persists plan cache information - a substitute for the dmv plan cache, which is cleared on reboot.
相关:
Related:
我不知道有什么工具可以自动执行此操作,但有几种选择。 将查询分成块...
每个 sql 完成时更新进度条。
或者您可以记录每个选择所花费的时间长度,可能基于每个用户存储这些值。 然后使用该信息返回进度条长度。
这两种方法都非常笨拙,希望有人知道更好的方法。
当然,您可以尝试破译查询计划并据此做出判断,但在代码中这会很困难。
I'm not aware of a tool that will do this automatically, but there are a couple of alternatives. Break your query into blocks ...
as each sql completes so update the progress bar.
Or you could record the length of time taken for each of your selects, store those values maybe on a per user basis. Then use that information to return a progress bar length.
Both these approaches are pretty kludgy, hopefully someone knows a better approach.
Of course you could try to decipher the query plan and make a judgement based on that, but in code that would be hard.