MySQL CLI 读数中经过的查询时间

Elapsed query time in MySQL CLI readout

给定一个查询:

SELECT * FROM users;

进入了两个不同的 MySQL 客户端,我得到了截然不同的运行时间(或者不管它叫什么):

1537 rows in set (0.01 sec)
1537 rows in set (0.36 sec)

这反映了 (LAMP) 应用程序中的体验,所以我正在尝试对其进行调试,但不知道具体计算中包含什么内容。

0.01 sec/0.30 sec 读数中包含什么?

编辑:这是 36 secs 查询中的 show profile

mysql> show profile;
--------------
show profile
--------------

+------------------------+----------+
| Status                 | Duration |
+------------------------+----------+
| Starting               | 0.000045 |
| checking permissions   | 0.000005 |
| Opening tables         | 0.000018 |
| After opening tables   | 0.000004 |
| System lock            | 0.000005 |
| table lock             | 0.000007 |
| init                   | 0.000037 |
| Optimizing             | 0.000009 |
| Statistics             | 0.000013 |
| Preparing              | 0.000015 |
| Executing              | 0.000002 |
| Sending data           | 0.010229 |
| End of update loop     | 0.000010 |
| Query end              | 0.000002 |
| Commit                 | 0.000004 |
| closing tables         | 0.000003 |
| Unlocking tables       | 0.000001 |
| closing tables         | 0.000007 |
| Starting cleanup       | 0.000002 |
| Freeing items          | 0.000006 |
| Updating status        | 0.000014 |
| Reset for next command | 0.000003 |
+------------------------+----------+
22 rows in set (0.05 sec)

加起来达不到那个数字(之前在“发送数据”时给出了 0.2363,但结果下降了,不知道为什么)。

以上评论汇总:

MySQL 客户端时间包括通过网络传输查询结果所需的时间,但查询配置文件时间不包括网络传输时间。由于报告时间快的客户端在AWS的一个实例上,因此靠近RDS数据库,预计会有更好的时间。

另一个客户端在 OP 的 Mac 上,因此数据必须通过 WAN 传输。根据结果​​集中1537行的长度,可以很容易地解释时间差异。

运行 使用 ping 检查从每个客户端到 RDS 服务器的网络延迟的一些测试应该会揭示一些差异。这是我笔记本电脑上的一个例子,ping Google DNS 服务器:

% ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=19.681 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=19.863 ms

这表明延迟低于 20 毫秒。我希望从您的 AWS MySQL 客户端到 AWS RDS 实例的延迟非常短,可能低于 2 毫秒。

吞吐量不同于延迟,但如果结果集足够大,它也会影响感知网络时间。我建议在您的云实例上使用 mysql 客户端将您的查询结果保存到文件中,然后在您的 Mac 上使用文件传输程序下载该文件,并查看需要多长时间。


回复您的评论:

How does anyone use RDS outside AWS if it performs like this?

不成功,除非他们的应用程序可以容忍高延迟。如果您需要一个应用程序在客户端和数据库之间具有非常低的延迟,那么请将客户端放在与数据库相同的区域。

同样的问题也会存在,例如,如果您在 AWS 中有一个客户端,但与您的 RDS 实例位于不同的区域。就像从 us-east-1.

中的客户端查询 us-west-2 中的 RDS

这不是获得更强大的计算机或新的网络技术可以解决的问题。它受到电速(即光速)的限制。但这是理论上的最佳情况,因为网络不是直线,交换机和网桥等连接点会产生一些额外的延迟。

同一地区的客户端访问数据库的速度要快得多,因为网络距离要短得多。即使他们在不同的可用区,只要他们在同一个AWS区域,延迟低到足以满足他们的需求。