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

Question

给定一个查询：

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 ，但结果下降了，不知道为什么）。

Answer 1

以上评论总结：

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

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

使用ping运行一些测试来检查。从每个客户端到 RDS 服务器的网络延迟应该会揭示一些差异。 这是我笔记本电脑上的一个例子，ping 谷歌 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 上使用文件传输程序下载该文件，并查看需要多长时间。

---

回复您的评论：

如果 RDS 表现如此，人们如何在 AWS 之外使用它？

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

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

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

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