查询执行时间

Question

我正在查询一个包含超过 5 亿条记录的 SQL Server 2008 数据库表。我发起的将大约 1000 万条记录移动到临时表的查询需要 9 个小时。我发起的类似查询已经持续了 10 多个小时。

如何知道：

1. 完成正在运行的查询所需的时间
2. 执行前完成查询所需的时间

Answer 1

某些语句在列中报告完成百分比：sys.dm_exec_requests percent_complete

以下命令完成的工作百分比：

• 更改索引重组
• 带有 ALTER DATABASE 的 AUTO_SHRINK 选项
• 备份数据库
• DBCC 检查数据库
• DBCC 检查文件组
• DBCC检查表
• DBCC 索引碎片整理
• DBCC 收缩数据库
• DBCC 收缩文件
• 恢复
• 恢复数据库，
• 回滚
• TDE 加密

对于其他声明，您将不得不等待并查看。

首先，您必须检查“查询”是否正在取得任何进展或只是闲置，阻止了其他事情。同样的DMV上面提到将立即显示这一点，wait_time，wait_type和wait_resource是一个死白送：如果他们改变，其进取，如果他们留固定的（wait_time增长）查询被卡住而blocking _session_id是拦截。

如果查询确实取得了进展，并且是一个移动行的单个查询，我必须说：一个不会四处走动，盲目地移动 10M 行。如果您在单个事务中执行此操作，那么您的事务日志在过去 10 小时内一直在不断增长。每个日志增长事件都是数据库的完全冻结，因为它等待日志扩展以将新分配的磁盘空间归零。然后活动将恢复，只是在短时间内达到一个新的增长事件。到现在为止，您的数据库日志很可能已经增长了数百倍。这发生在所有恢复模式下，包括 SIMPLE。

您可以中止查询，但必须等到 10 个小时的事务回滚。一个 10 小时的事务可能需要另外 10 小时才能回滚，或多或少，这取决于许多因素。

您可以在恐慌中关闭服务器并重新启动它，只会面对试图撤消 10h 事务的数据库的恢复。恢复将持续，保证，比回滚事务更长。

所以这就是为什么在单个“查询”中永远不会移动 10M 行的原因。必须在较小的集合中批量移动。当然，这需要精心编写的程序才能做到。

一些用户很幸运，他们通过在这样的帖子上绊倒并记下自己“不要在一次操作中移动 10M 行”来学习。其他人很难学习……但他们（希望）下次知道得更好。