Question

我正在考虑将我的网站迁移到Google Cloud SQL，然后我注册了一个免费帐户（D32）。

在有23k记录的桌面上测试时，表现非常差，所以我读到如果我从免费帐户转到完全付费帐户，我可以访问更快的CPU和HDD ......所以我做了。

表演仍然非常糟糕。

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

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

我将涉及这些众多查询的表格上传到Google Cloud SQL。我注意到INSERT已经执行SECONDS而不是毫秒......但我认为它可能是sync vs 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

Query cache is not as yet a feature of Cloud SQL. This may explain the results. However, I recommend closing this question as it is quite broad and doesn't fit the format of a neat and tidy Q&A. There are just too many variables not mentioned in the Q&A and it doesn't appear clear what a decisive "answer" would look like to the very general question of optimization when there are so many variables at play.

Answer 2

我知道这个问题很老但是......

CloudSQL对MyISAM表的支持不足，建议使用InnoDB。

我们在迁移旧版应用时效果不佳，在阅读了文档并联系付费支持后，我们不得不将表格迁移到InnoDB;没有查询缓存也是杀手锏。

您稍后可能会发现，您需要通过“标记”来调整mysql conf。在谷歌控制台。一个例子是＆＃39; wait_timeout＆＃39;默认情况下设置得太高（imo。）

希望这有助于某人:)

Google Cloud SQL非常慢

2 个答案: