mysql持续时间和获取时间答案

【问题标题】：mysql duration and fetch timemysql持续时间和获取时间
【发布时间】：2012-03-14 13:43:11
【问题描述】：

我正在使用 MySQL 工作台 - 运行查询时，持续时间和获取时间有什么区别？

还有什么方法可以在 MySQL 中启用微秒选项？

【问题讨论】：

奇怪的赏金。所有的答案都是正确的，但你只是不相信他们？ Here 和 here 是在 mysql 论坛上为 Oracle 工作的 Mike Lischke 提供的完全相同的答案。够靠谱吗？

【解决方案1】：

获取时间 - 衡量传输获取的结果需要多长时间，这与查询执行无关。我不会将其视为 sql 查询调试/优化选项，因为获取时间取决于网络连接，而网络连接本身与查询优化没有任何关系。如果获取时间是瓶颈，那么更有可能存在一些网络问题。

注意：每次查询执行的获取时间可能会有所不同。

持续时间 - 是查询需要执行的时间。在优化 sql 查询的性能时，应该尽量减少它。

【讨论】：

出于优化目的，请记住选项query_cache_type 必须为OFF，以使结果不受缓存影响。见stackoverflow.com/questions/181894/…
虽然我同意 duration 是您通常想要优化的值，因为它直接关系到您的查询效率，异常高 fetch时间还可以指出重要的逻辑错误和/或低效率。例如，您可能会在客户端应缓存的每个查询中传输大量文本。或者，当您只期望 10 行时，您可能会返回 100k 行。
好点 @GrandOpener - 或者当您真正需要的只是行 ID 时，您可以执行 select(*)。
这似乎不对。我有两个查询返回相同的行（15300），但它们的统计数据总是不同的。一个需要 14,443 秒持续时间 / 1111,810 秒获取，其他 443,986 秒持续时间 / 0,0089 秒获取每次。这是为什么呢？
如果是这种情况，那么对于 select 语句中的固定数量的列和结果的固定限制，如果交付了有限项目的数量，则获取时间应该总是或多或少相同.我使用了一个 sql - 查询，我更改了 where - 子句，并且获取时间需要比没有 where 子句的时间长 40 秒。在 where 子句中，我使用了引用另一个表的子查询。 duration 不会发生显着变化，但获取时间会发生显着变化。这怎么可能？

【解决方案2】：

Duration 表示执行查询所需的时间，而 fetch 是读取结果集（检索数据）所需的时间

我不确定微秒选项。如果这是关于优化，请记住——“过早的优化是万恶之源”

【讨论】：

【解决方案3】：

Leri 的回答是一个好的开始，但忽略了 MySQL 可以在获得所有查询结果之前将数据流式传输到客户端的事实。

下面是一个示例，其中有 2 个查询具有相同的结果。第一个使用 group by，因此 MySQL 必须在发送所有数据之前计算完整聚合。第二个使用子查询，因此 MySQL 逐行计算结果集，并能够立即将第一行结果发送给客户端。

如您所见，第二次查询的获取时间长了 5 倍（对于相同的数据），因为 MySQL Workbench 将第一次收到数据之前的时间显示为 Duration 和之后的时间为 Fetch，但由于可能涉及流式传输，并不意味着 fetch 持续时间仅为网络持续时间。

在 Fetch 期间，数据库可能仍在计算结果。所以，如果你看到一个很大的 fetch 持续时间，你实际上可以做一些事情！这可能意味着您的 MySQL 数据库正在逐行流式传输结果，并且正在努力计算完整的结果集。

【讨论】：

【解决方案4】：

执行时间是准备查询和运行查询所花费的时间 AND 获取时间是拉入行结果所花费的时间

【讨论】：

【解决方案5】：

关于微秒，尝试在 Preferences 菜单中启用它，我之前也有一个关于持续时间和获取时间的问题，现在我似乎得到了持续时间是查询的执行时间的答案，而 fetch是检索结果并将它们发送到您想要的任何地方。例如，我得到一个持续时间为 0.078 的查询，但需要 60 秒才能将数据发送回我的网站。

【讨论】：