RDS: Long_query_time工作很奇怪

Question

【以下的问题经过翻译处理】 你好。我有一个RDS (8.0.mysql_aurora.3.02.0)实例。我通过启用“慢查询日志”功能进行修改，以查看CloudWatch中所有缓慢的请求。此外，我附加了一个 custom parameter group，其中包含 slow_query_log = 1、log_output = FILE和long_query_time = 0.3。我发送了一些请求以查看它的工作方式。

使用MySQL workbench，我可以看到请求时间: Duration = 0,468 sec和Fetch = 0,620 sec。此请求未在CloudWatch中注册。因此，我创建了更大的请求，在Cloudwatch中也能看到一个请求时间为1的行：Duration = 0,376 sec和Fetch = 0,923 sec，
并且在CloudWatch中我看到了下一个请求时间：Query_time: 0.830316 Lock_time: 0.000123。
使用不同的SQL请求，我无法获得CloudWatch约为0.3秒的指标。最小的已注册请求是0.7秒。

所以我有问题：

• 如何有效的在AWS RDS中测量请求时间？
• 为什么MySQL Workbench和CloudWatch记录之间的请求时间不同？

Answer

【以下的回答经过翻译处理】 在MySQLWorkBench中，

Duration Time(持续时间) - 是查询需要执行的时间。在优化sql查询性能时，应尝试将其最小化。

Fetch Time(获取时间) - 测量传输抓取结果所需的时间，与查询执行无关。我不认为它是SQL查询调试/优化选项，因为获取时间取决于网络连接，它本身与查询优化无关。如果获取时间是瓶颈，则更有可能存在某些网络问题。

注意：获取时间因为有时结果被缓存而可能在每次查询执行时有所不同，因此它们可以更快地发送出去。

有关MySQLWorkBench中持续时间和获取时间的更多信息，请参见下面的论坛。我们确实有几篇第三方文章解释了相同的内容。

[+]

当涉及到MySQL慢查询日志时，

[+]

查询时间：持续时间为秒数。

锁定时间：获取锁定所需时间，以秒为单位。

我使用MySQL客户端和MySQL Workbench中的以下设置进行了简单的测试，但是我在控制台中的SlowQuery日志和CloudWatch中的SlowQuery日志的执行时间方面没有发现任何差异。

**版本：8.0.mysql_aurora.3.02.0**

**slow_query_log = 1**

**log_output = FILE**

**long_query_time = 0.3**

从MySQL终端：

--------------------

mysql> select sleep(10);
+-----------+
| sleep(10) |
+-----------+
| 0 |
+-----------+
1 row in set (10.00 sec)

mysql> select sleep(1);
+----------+
| sleep(1) |
+----------+
| 0 |
+----------+
1 row in set (1.01 sec)

mysql> select sleep(0.5);
+------------+
| sleep(0.5) |
+------------+

RDS: Long_query_time工作很奇怪

相关内容