Performance 谷歌云SQL很慢

我有一个D0大小的云SQL实例。当我运行一个简单的

select * from table

它大约有500行，执行平均需要100毫秒（正如SQL提示符所报告的）。而在我的本地MySQL 5.5实例上，它只需要1毫秒。我的开发机器有2.9GHz双核Intel core i7和8GB 1600MHz内存。我在一篇文章中读到，db的性能取决于大小——较大的实例有更多的RAM和CPU

期望通过更大的实例大小解决性能问题是否合理？还是我错过了什么

您从哪里连接到云SQL实例

层级大小将对性能产生很大影响。您可以临时更改实例的层以对其进行测试

---

编辑：2016年4月10日

GAE现在提供了第二代云mysql，即使是像“db-g1-small”这样的基本层，其性能也与旧云SQL产品中的D8层一样快。它也非常便宜。这似乎是一个重大的里程碑，没有理由再求助于黑客和变通办法

您可以参考云SQL定价，但最低成本约为每月20美元

原创帖子

Google只是在D0层的一个慢速框中设置VM。您可以选择D4，但RAM并不像处理器那样是主要问题（他们没有提到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月

---

对于一些应用程序，我不再使用云SQL，而是使用远程托管的基本MySql集群，因为GAE打开了出站套接字连接。听起来很疯狂？与数字不符-通过此套接字连接发送查询并获取数据要比同一位置的D3快。

视图是性能差的原因。谷歌运行自己风格的MySQL引擎，该引擎的优化方式可能会损害视图。如果有许多联接或/和联接，则视图运行速度会很慢

---

然而，我发布这个问题已经快一年了，事情可能已经改变了。自从我们不再使用视图后，我就再也没有访问过视图。

我们也遇到了同样的问题。 对于D16实例，加载一个简单的网站论坛页面需要>10秒。 我刚刚和一位谷歌云技术支持工程师谈过，他确认CloudSQL并没有真正做好“性能”准备（截至2015年夏天），他建议重写所有内容以使用数据存储

---

因此，如果您的页面有十几个小SQL查询，并且数据集太大，无法完全放入缓存，那么CloudSQL目前不是一个可行的解决方案。

以下是我们在2019年1月的更新

使用Google Cloud SQL第二代，在4vcpu+15GB RAM实例中使用46GB数据库，我们发现，即使与运行默认mysql安装（仅分配125MB内存）的dev macbook pro相比，它的速度也可能慢得离谱：

---

这是一项云服务。您必须考虑网络延迟。宇宙中最快的分贝仍然会很慢，如果你的管道通向它只是几个罐头和一根绳子，人们在里面喊1和0。把它排成1000、10000行，然后检查它是否线性扩展。如果是这样，你就有问题了。但我不认为会，因为持续的开销（网络延迟）。我相信，SQL提示符报告的是实际的查询执行时间，而不是SQL查询+网络延迟。正如Chrome开发工具报告的那样，延迟大约为400毫秒。我有一个视图，可以实现4个表的联合。在本地，从视图执行select*需要10毫秒，在云SQL上需要600毫秒，延迟为1秒。@mnagel，我将其设置为10000行。与SQL提示符下的报告执行相同的100毫秒。1。我正在从浏览器中的SQL提示符进行连接。2.我将尝试更改层大小并发布结果。我切换到D32实例（最大的一个），查询一个包含两条记录的表需要30毫秒。查询500条记录的表需要75毫秒，我认为这是不合理的。Amazon RDS在不到1毫秒的时间内完成所有这些操作。你知道为什么吗？我也遇到过同样的问题。我只运行了一行“select*from”形式的查询，sql提示符测量的查询时间为200毫秒。同样的延迟问题。。。简单语句需要1秒，在本地（到GCE中的VM）只需要0,01秒。。。延迟减少100倍…事情没有改变。似乎200ms是平均响应时间，但还不错。令人震惊的是，我们已经开发了几个月的hole系统来使用cloudSQL。你为什么说从夏天开始。。它有更好的表现，还是从那时起就开始落后于其他供应商？数据存储根本不符合我们的需要。有什么建议吗？我也是云平台支持人员，这个特定案例似乎是一个特定于用例的建议，而不是一个“Datatsore>Cloud SQL”的笼统的全局声明。你真的应该在每页加载时打几十个电话吗？在任何情况下，这似乎都不是一个理想的整体计划。@cfl您可以将其替换为使用另一个托管MySQL服务，例如RDS。这是一个遗憾。我认为，到2020年3月为止，情况并没有好转。令人震惊。我们必须迁移回AWS RDSNovember 2020：糟糕透了。正在尝试Kamatera。AWS是下一个。太遗憾了……好吧，让我们停止发送关于日期的评论，因为它似乎永远不会被修复，我的意思是，现在是2022年，选择123需要

478

mili秒（postgresql）。