谷歌云 SQL 很慢答案

【问题标题】：Google Cloud SQL is slow谷歌云 SQL 很慢
【发布时间】：2013-09-08 05:07:41
【问题描述】：

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

select * from table

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

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

【问题讨论】：

它是一种云服务。你HAVE允许网络延迟。宇宙中最快的数据库仍然会很慢，如果你通往它的管道只是几个锡罐和一根绳子，里面有人喊着 1 和 0。
使它成为 1000、10000 行并检查它是否线性缩放。如果确实有问题。但我认为不会，因为开销不断（网络延迟）。
我相信，SQL Prompt 报告的是实际查询执行时间，而不是 SQL 查询 + 网络延迟。根据 Chrome Dev Tools 的报告，延迟约为 400 毫秒。
我有一个合并 4 个表的视图。在本地，执行 select * from view 需要 10 毫秒，在 Cloud SQL 上是 600 毫秒，延迟是 1 秒。
@mnagel，我做了 10000 行。与 SQL Prompt 报告的执行时间相同的 100 毫秒。

标签： performance google-cloud-sql

【解决方案1】：

这是我们在 2019 年 1 月的更新。

在 4vcpu + 15GB RAM 实例中使用具有 46GB 数据库的 Google Cloud SQL SECOND GENERATION，我们发现即使与运行默认 mysql 安装且仅分配 125MB 内存的 dev macbook pro 相比，它也可能非常慢：

Mysql: Google Cloud SQL with 10GB RAM is 20x slower than Macbook Pro configured with 125MB ram

【讨论】：

这是一种耻辱。
截至 2020 年 3 月，情况并没有好转。令人震惊。我们必须迁移回 AWS RDS
2020 年 11 月：太糟糕了。尝试卡马泰拉。 AWS 是下一个。真可惜……
好的，让我们停止发送有关日期的 cmets，因为它似乎永远无法修复，我的意思是，它是一年 2022 和 SELECT 123; 需要 478 mili-seconds (postgresql )。

【解决方案2】：

视图是导致性能不佳的原因。谷歌运行他们自己风格的 MySQL 引擎，该引擎以一种可能会损害视图的方式进行了优化。如果您有许多联接或/和联合预计视图运行缓慢。

但是，我发布这个问题已经快一年了，情况可能已经发生了变化。自从我们不再使用视图后，我就没有重新访问过视图。

【讨论】：

事情没有改变。似乎 200 毫秒是平均响应时间，不过还不错。

【解决方案3】：

编辑：2016 年 4 月 10 日

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

您可以参考 Cloud SQL 定价，但最低费用约为每月 20 美元。

原帖

Google 只是在 D0 层的慢速机器上配置 VM。您可以选择 D4，但 RAM 与处理器相比不是主要问题（他们没有提到 GHz）。

网络延迟不是问题。例如下面的 0.05s 只是服务器上的查询执行时间。此后的任何时间都可以用于数据传输。

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 更快。

【讨论】：

【解决方案4】：

您从哪里连接到 Cloud SQL 实例？
层大小将对性能产生很大影响。您可以临时更改实例的层以对其进行测试。

【讨论】：

1.我在浏览器中从 SQL 提示符developers.google.com/cloud-sql/docs/sql_prompt 连接。 2. 我会尝试改变层级大小并发布结果。
我切换到 D32 实例（最大的一个），查询一个有两条记录的表需要 30 毫秒。查询 500 条记录的表需要 75 毫秒。我认为这是不合理的。 Amazon RDS 在不到 1 毫秒的时间内执行所有这些操作。你知道为什么会这样吗？
我也遇到了同样的问题。我运行了一个形式为“select * from ”的查询，只有 1 行，通过 sql 提示测量的查询时间花费了 200 毫秒。

延迟问题相同...简单语句需要 1 秒，而它在本地（到 GCE 中的虚拟机）只需 0.01 秒...延迟减少 100 倍...

【解决方案5】：

我们也遇到了同样的问题。使用 D16 实例，加载一个简单的网站论坛页面需要 10 秒以上。我刚刚与一位 GoogleCloud 技术支持工程师交谈，他确认 CloudSQL 还没有真正为“性能”做好准备（截至 2015 年夏季），他建议重写所有内容以使用 DataStore...

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

【讨论】：

这令人震惊，几个月来一直在开发我们的孔系统以使用 cloudSQL。你为什么说从夏天开始......它有更好的表现还是从那以后开始落后于其他供应商？ Datastore 根本不符合我们的需求。有什么建议吗？
我也来自 Cloud Platform Support，这个具体案例似乎是针对用例的建议，而不是“Datatsore > Cloud SQL”的笼统全局声明。
您真的应该在每次页面加载时进行数十次调用吗？无论如何，这似乎不是一个总体上不理想的计划。
@cfl 您可以将其换出以使用另一个托管 MySQL 服务，例如 RDS。