Google Cloud SQL非常慢

Question

我正在考虑将我的网站迁移到Google Cloud SQL,然后我注册了一个免费帐户(D32).

在有23k记录的桌子上进行测试时,性能非常差,所以我读到如果我从免费帐户转到完全付费帐户,我可以访问更快的CPU和HDD ...所以我做到了.

表演仍然非常糟糕.

我正在运行我自己的MySQL服务器多年,根据需要升级以处理越来越多的连接并获得原始速度(由于遗留应用程序需要).我高度优化表,配置和大量使用查询缓存等...

我们遗留系统的几页每页有超过1.5k的查询,目前我能够将所有查询的mysql查询时间(执行和拉动数据)推迟到3.6秒,这意味着MySQL需要大约0.0024秒执行查询并返回值..不是最大但可接受的那些页面.

我将涉及这些问题的表格上传到Google Cloud SQL.我注意到INSERT已经执行SECONDS而不是毫秒......但我认为它可能是syncvs async设置.我将其更改为async并且插入的执行时间不会改变.现在不是一个大问题,我现在只测试查询.

我运行一个简单的select * FROM <table>,我注意到它需要超过6秒..我认为可能查询缓存需要构建..我再试一次,这次需要4秒(不包括网络流量).重启后我在备份服务器上运行相同的查询,根本没有连接,只需不到1秒......再次运行,0.06秒.

也许问题是缓存,太大了......让我们尝试一个较小的子集

select * from <table> limit 5;

• 到我的服务器:0.00秒
• GCS:0.04

所以我决定在空桌上尝试一个愚蠢的选择,根本没有记录,只用1个字段创建

• 到我的服务器:0.00秒
• GCS:0.03

分析不会提供任何见解,除了查询缓存没有在Google Cloud SQL上运行,并且查询执行似乎更快但......不...

我的服务器:

mysql> show profile;
+--------------------------------+----------+
| Status                         | Duration |
+--------------------------------+----------+
| starting                       | 0.000225 |
| Waiting for query cache lock   | 0.000116 |
| init                           | 0.000115 |
| checking query cache for query | 0.000131 |
| checking permissions           | 0.000117 |
| Opening tables                 | 0.000124 |
| init                           | 0.000129 |
| System lock                    | 0.000124 |
| Waiting for query cache lock   | 0.000114 |
| System lock                    | 0.000126 |
| optimizing                     | 0.000117 |
| statistics                     | 0.000127 |
| executing                      | 0.000129 |
| end                            | 0.000117 |
| query end                      | 0.000116 |
| closing tables                 | 0.000120 |
| freeing items                  | 0.000120 |
| Waiting for query cache lock   | 0.000140 |
| freeing items                  | 0.000228 |
| Waiting for query cache lock   | 0.000120 |
| freeing items                  | 0.000121 |
| storing result in query cache  | 0.000116 |
| cleaning up                    | 0.000124 |
+--------------------------------+----------+
23 rows in set, 1 warning (0.00 sec)

Google Cloud SQL:

mysql> show profile;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000061 |
| checking permissions | 0.000012 |
| Opening tables       | 0.000115 |
| System lock          | 0.000019 |
| init                 | 0.000023 |
| optimizing           | 0.000008 |
| statistics           | 0.000012 |
| preparing            | 0.000005 |
| executing            | 0.000021 |
| end                  | 0.000024 |
| query end            | 0.000007 |
| closing tables       | 0.000030 |
| freeing items        | 0.000018 |
| logging slow query   | 0.000006 |
| cleaning up          | 0.000005 |
+----------------------+----------+
15 rows in set (0.03 sec)

请记住,我从位于VA的服务器远程连接到两台服务器,而我的服务器位于德克萨斯州(即使它不应该那么重要).

我究竟做错了什么 ？为什么简单的查询需要这么久？我在这里遗失或不理解某事吗？

截至目前,我将无法使用Google Cloud SQL,因为包含1500个查询的页面将占用太长时间(大约45秒)

Answer 1

查询缓存目前还不是 Cloud SQL 的一项功能。这可以解释结果。但是，我建议关闭这个问题，因为它非常广泛，不适合整洁的问答格式。问答中没有提到太多的变量，而且当有如此多的变量在起作用时，对于非常普遍的优化问题来说，决定性的“答案”看起来是什么样子似乎并不明确。