我正在考虑将我的网站迁移到Google Cloud SQL，并注册了一个免费帐户（D32）。
在一张有23k条记录的表上测试后，性能非常差，所以我读到，如果我从免费账户转到全额付费账户，我将可以使用更快的CPU和HDD。。。我照做了。
表演仍然很差。
多年来，我一直在运行自己的MySQL服务器，根据需要进行升级，以处理越来越多的连接并获得原始速度（因为遗留应用程序需要）。我高度优化了表、配置和大量使用查询缓存等…
我们的遗留系统的一些页面每页有超过1.5k的查询，目前我能够将所有这些查询的mysql查询时间（执行和提取数据）降低到3.6秒，这意味着mysql执行查询和返回值大约需要0.0024秒。。不是最好的，但对那些页面来说是可以接受的。
我上传了一个涉及这些查询的表到谷歌云SQL。我注意到INSERT的执行时间已经是秒，而不是毫秒。。但我认为这可能是sync与async的设置。我将其更改为async，并且插入的执行时间感觉没有变化。现在不是什么大问题，我现在只测试查询。
我运行了一个简单的select * FROM <table>，我注意到它需要6秒以上。。我认为可能需要构建查询缓存。。我再试一次，这次需要4秒（不包括网络流量）。重新启动后，在完全没有连接的情况下，我在备份服务器上运行相同的查询，所需时间不到1秒。。再次运行0.06秒。
也许问题是缓存太大了。。。让我们试试更小的子集
select * from <table> limit 5;
- 到我的服务器：0.00秒
- GCS:0.04
所以我决定在一个空表上尝试一个愚蠢的选择，根本没有记录，只创建了一个字段
- 到我的服务器：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)
谷歌云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)
请记住，我从位于弗吉尼亚州的服务器远程连接到这两个服务器，并且我的服务器位于德克萨斯州（即使这并不重要）。
我做错了什么？为什么简单的查询需要这么长时间？我是错过了什么还是不明白什么？
到目前为止，我将无法使用Google Cloud SQL，因为一个有1500个查询的页面将花费太长的时间（大约45秒）
我知道这个问题很老，但。。。。
CloudSQL对MyISAM表的支持很差，建议使用InnoDB。
我们在迁移遗留应用程序时表现不佳，在阅读了文档并联系了付费支持后，我们不得不将表迁移到InnoDB中；没有查询缓存也是一个杀手。
稍后您可能还会发现，您需要通过谷歌控制台中的"flags"来调整mysql-conf。例如"wait_timeout"在默认情况下设置得太高（imo.）
希望这能帮助到某人：）
查询缓存还不是云SQL的一个功能。这可以解释结果。然而，我建议结束这个问题，因为它非常宽泛，不适合整洁的问答形式；A.问答中没有提到的变量太多了；A，当有这么多变量在起作用时，对于优化这一非常普遍的问题，决定性的"答案"会是什么样子似乎还不清楚。