为什么显示SQL语句的进度是不切实际的？

Question

我正在处理一个大型数据集，有些语句需要30-70分钟才能执行，这是一个令人沮丧的月份！

我只是想知道...... SQL实现通常不会报告单个执行计划的进展吗？或者只是对大多数人来说这不够重要？

请赐教我。

Answer 1

SQL中的大多数操作都是以基于集合的方式执行，逻辑上只是一步。因此除了结果本身之外没有进展报告。

实际的SQL实现必然需要多个执行步骤来完成单个逻辑步骤;但是，任何给定的SQL引擎都可能将其方法从执行更改为执行（基于数据量，索引，并行性等），因此报告进度可能不可靠和/或误导

Answer 2

因为知道剩下多少工作需要事先知道需要完成多少工作，这意味着您必须先前运行查询。

由于基础数据集可以改变，缓存可能处于不同的压力水平等等......一次运行查询所需的时间与它需要多长时间的关系可能很少（或根本没有）下一次。

充其量你可以做一个估计，并最终得到“4小时30分钟剩余”，因为事情突然变得比估计允许的速度慢很多。

Answer 3

我认为主要原因很简单，没有太多要求它。在某些情况下提供可能准确的糟糕进度指标并不是那么多工作。但是提供一个实际可靠的进度指示器是一项非常多的工作，在某些情况下几乎是不可能的。

例如，假设查询需要查找满足某组条件的所有记录，然后转到另一个表以查看它们是否通过了其他一些条件。要提供有用的进度指示器，您需要知道要在另一个表中检查的记录数。但在找到所有记录之前，你无法知道。

你可以天真地猜测每次操作都需要一半的时间。这将提供一个进度条，提供前进动作，并在操作完成时到达结束。所以它并非毫无用处。但是上半部分可能会拖延几个小时然后下半部分立即完成（例如，如果找不到匹配的记录）。或者你可能会在前半段加速，然后以50％的速度慢下来。

所以基本上，任何进度条都会让你相信它没有放弃。

Answer 4

每次添加进度指示器时，都会人为地降低处理速度。毕竟，程序需要时间来停止它正在做的事情，增加一些值，将该值发送回调用程序等。

对于SQL查询，这通常是一个很大的禁忌。特别是在阻塞服务器可能有其他查询等待执行的阻塞情况下..

听起来我觉得你有两个问题之一。要么你有一个高度未经优化的过程，要么你的服务器太强大，无法处理你的处理。我会考虑修复其中一个（或两个）。通常这是需要修复的过程。