Amazon RDS MySQL 实例执行速度非常慢答案

【问题标题】：Amazon RDS MySQL instance performs very slowAmazon RDS MySQL 实例执行速度非常慢
【发布时间】：2013-04-08 19:03:14
【问题描述】：

我已在 Amazon EC2（新加坡地区）上发布了我的网站，并使用 MySQL RDS 实例进行数据存储。除了性能，一切都运行良好。

我的所有查询，尤其是 select 语句，似乎都执行得很慢。如果我在本地 PC 上检查此问题，它运行得非常好。但是当我试图从 RDS 实例中获取数据时，它非常慢。某些 select 语句需要 2-3 秒才能获取数据。

我已经正确调整了所有表索引，并根据需要进行了规范化/反规范化。我已对 RDS 自定义参数组（例如 max_connection、buffer 等）进行了所有必要的设置。我不知道我是否遗漏了什么，但它对我没有用 - 性能没有提高。

那么，有人可以帮我解决这个问题吗？

【问题讨论】：

只是为了理解..您使用的是哪个实例？
我也有同样的问题。我尝试使用 Digital Ocean 设置 RDS——页面加载（依赖于 DB）从平均 1.8 秒变为 5.9 秒。因此，在同一区域/集群和同一时区中重新创建了 EC2 和 RDS 中的整个设置。我也设置了缓存。

标签： mysql amazon-web-services amazon-s3 phpmyadmin amazon-rds

【解决方案1】：

假设系统具有更高的读取率，可以通过以下方式提高 RDS MySQL 性能：

使用更大的实例类型，它们具有更好的 NW 带宽。示例 AWS Quadruple EXL 具有 1,000 Mbps 带宽。
使用 PIOPS 存储可以从 MySQL 数据库中提取 16KB 的 12,500 IOPS
如果执行大量读取，请添加一个或多个只读副本以提高读取性能
应用标准做法，例如：调整查询、应用索引等

【讨论】：

【解决方案2】：

重要的是让您的 RDS 和 EC2 实例不仅在同一个区域，而且在同一个可用区，以最大限度地减少延迟。

我在爱尔兰的 EC2 上托管了一个 API，并将数据库移动到美国弗吉尼亚州的一个 MySQL 集群，该集群是我们为另一个项目设置的，每个 SQL 查询的往返都导致 API 无法使用。

【讨论】：

RDS 和 EC2 在同一个可用区意味着它们在同一个区域
你刚刚赚了我一个月
我不明白这个答案是如何在没有评论在 API 和 DB 之间使用防火墙的情况下获得支持的，而且它们还必须通过 Tor 网络上的 VPN 隧道连接 - 以获得更好的安全性— 努力优化你的堆栈！

【解决方案3】：

值得注意的是，无论出于何种原因，RDS 中 MySQL 查询缓存默认是关闭的。这周我们自己也学会了这一点。

这不会帮助您提高初始查询的性能，但总体上可能会加快速度。

要重新启用查询缓存：

登录 RDS 控制台
单击您的 RDS 实例以查看其详细信息
编辑数据库参数组
请务必同时设置query_cache_size 和query_cache_type

（免责声明：我不是 DBA，所以我可能在这里遗漏了其他东西）

【讨论】：

对于 InnoDB 表，您应该保持关闭。参考：serverfault.com/questions/604315/…
将 query_cache_type 设置为 1 也解决了我的速度问题。我还将thread_cache_size 从 8 更改为 24，将 innodb_io_capacity 从 200 更改为 1900。

【解决方案4】：

首先我强烈建议使用

查看这些查询

显示完整的进程列表

您可以在 SHOW FULL PROCESSLIST 上阅读更多相关信息

这将显示每个查询所用的时间。

然后就可以使用了

解释

您可以在EXPLAIN上阅读更多信息

这将显示您是否需要对查询进行一些增强

【讨论】：

问题是关于本地和 AWS 中执行查询之间的区别，而不是关于慢查询
我有一组带有 DDL 的“迁移”脚本，用于创建数据库结构。以及带有“种子”数据的文件列表。我在本地和 AWS 中运行它们，因此，我有两个 相同的（表、索引、...和表项）数据库。我在两个数据库中都运行“EXPLAIN”——解释相同，但在 AWS 中，请求（REST + SQL）需要 900 毫秒，而在本地（在一个非常有限的系统中，有两个 Docker 映像——DB + nginx）需要 70 毫秒。

【解决方案5】：

您可以使用分析来检查查询在哪里花费时间。使用以下查询：

设置分析=1
执行您的选择查询
显示个人资料

这将告诉您查询的状态以及查询花费的时间。如果分析返回的所有时间的总和小于查询的实际执行时间，那么可能是其他因素，如网络带宽。

【讨论】：

【解决方案6】：

对我来说，这与 MySQL 无关，而是我在 t2.medium 上的实例类型。问题是我用完了 CPU 积分，因为数据库上的负载太高，余额一直下降，直到最后，我每小时获得的积分远远少于所需的积分。

这是我在 RDS CloudWatch 中的 CPU Credit Usage 下看到的：

如果您遇到同样的问题，可能是时候切换到其他实例了。以下是实例类型列表：

https://aws.amazon.com/rds/instance-types/

希望这会有所帮助。

【讨论】：

你是怎么进入这个屏幕的？
它在“监控”下
RDS > 数据库 > [YOUR_DB_NAME]，在页面底部选择“监控”，单击任意图表，然后将左上角的下拉菜单导航至 CPU Credit。确保将时间段缩小到您上次记得它运行良好的时候。
必须从 db.t2.micro 升级到 db.t3.micro 实例：...虽然一旦 CPU 积分余额降至零，Amazon RDS T2 实例就会受限于基准性能，但 Amazon即使其 CPU 积分余额为零，RDS T3 实例也可以突增到基线之上。 ...来源：aws.amazon.com/rds/instance-types

【解决方案7】：

始终应将 source 和 rds 部署在同一 AWS 可用区以降低网络延迟，并应在 VPC 中为 RDS 创建私有端点链接，以通过内部网络连接 RDS 端点，而不是通过 Internet 路由。

参考：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/vpc-interface-endpoints.html

【讨论】：

【解决方案8】：

我发现迁移到 RDS 后，我所有的数据库索引都消失了！它们没有与架构和数据一起迁移。确保您的索引在那里。

【讨论】：