我有一个D0规格的Cloud SQL实例。当我运行一个简单的
select * from table
这个数据库表大约有500行数据，平均需要100毫秒的时间来执行查询（由SQL Prompt报告）。然而，在我本地的MySQL 5.5实例中，只需要1毫秒的时间。我的开发机器是2.9GHz双核Intel Core i7和8GB 1600MHz内存。我在一个FAQ中读到，数据库性能取决于其规模 - 更大的实例有更多的RAM和CPU。
是否可以合理地期望通过提高实例大小来解决性能问题？或者我还有其他遗漏的问题吗？
以下是我们在2019年1月的更新。
我们使用Google Cloud SQL SECOND GENERATION，在一个4vcpu+15GB RAM实例中运行一个46GB的数据库，发现它甚至比一个只分配了125MB内存的dev macbook pro默认安装的mysql还要慢得离谱：
Mysql：Google Cloud SQL配备10GB RAM比配置了125MB RAM的Macbook Pro慢20倍
SELECT 123;需要478毫秒（postgresql）。 - Top-Master编辑：2016年4月10日
现在GAE提供了第二代云mysql，即使是像“db-g1-small”这样的基本级别也可以像旧的Cloud SQL提供的D8级别一样快速运行。而且价格也便宜得多。这似乎是一个重要的里程碑，不再需要使用hack和解决方法。
您可以参考Cloud SQL的定价，但最低费用大约为每月20美元。
原始文章
Google只为D0层配置慢速服务器，您可以选择D4，但内存并不是主要问题，处理器才是主要问题（他们没有提到GHz）。
网络延迟不是问题。例如，下面的0.05秒是仅在服务器上执行查询所需的时间。之后的任何时间都可能花费在数据传输中。
mysql> select * from tracking limit 5;
+--------------------------------+-----------+-----------+
| id | scan_date | status |
+--------------------------------+-----------+-----------+
| 420006929400111899561510697350 | NULL | Delivered |
| 420010859400111899561989496058 | NULL | Delivered |
| 420019849400111899561989496331 | NULL | Delivered |
| 420100109400111899561903290311 | NULL | Delivered |
| 420100319400111899561944407020 | NULL | Delivered |
+--------------------------------+-----------+-----------+
5 rows in set (0.05 sec)
编辑：2016年3月
对于一些应用程序，我不再使用Cloud SQL，而是使用远程托管的基本MySql集群，因为GAE打开了出站套接字连接。听起来很疯狂？但从数字上看，通过此套接字连接发送查询并获取数据比同地D3更快。
性能不佳的原因是视图。Google运行自己优化过的MySQL引擎，这种优化可能会损害视图。如果您有许多连接或/和联合，请预计视图运行缓慢。
然而，自从我发表了这个问题已经快一年了，情况可能已经改变了。自从我们停止使用视图以来，我还没有重新审视过它们。