从 mysql-5.5 升级到 mysql-5.6 后查询速度变慢

Question

有很多关于 MySql 5.6 如何比 MySql 5.5 更快的文章（例如http://dev.mysql.com/tech-resources/articles/mysql-5.6.html），但我们升级了我们的 Amazon RDS 实例（使用新的升级程序) 并发现每个页面视图在数据库中花费的平均时间变得更糟，从 30 毫秒到 50 毫秒 - 显着减慢。

这是每个页面视图在数据库中花费的时间（每秒大约 1000 次查询）的图表（来自 newrelic）：

放缓似乎是在简单的 UPDATE 语句上。我不希望它们成为问题，因为使用了 PK。此示例显示了一个执行耗时 6 秒但解释计划最佳的语句（表中的行数：700k）：

mysql> EXPLAIN UPDATE users SET type='dual', updated_at=NOW() where user_id=1234;
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table   | type  | possible_keys | key     | key_len | ref   | rows | Extra       |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+
|  1 | SIMPLE      | users   | range | PRIMARY       | PRIMARY | 4       | const |    1 | Using where |
+----+-------------+---------+-------+---------------+---------+---------+-------+------+-------------+

updated_at=NOW() 似乎是新推出的缓慢声明中的一个共同主题。

MySQL 5.6 是否有任何原因更新较慢？有没有人知道我可以检查什么来调试这种减速？

---

其他信息：实例大小： db.m2.4xlarge ， query_cache 已关闭。performance_schema 已关闭。确切版本：原为：5.5.27，现在为：5.6.16。

Answer 1

问题是我们的新 RDS 实例在 writeIOPS 上受到限制，我们可以看到排队的磁盘操作（DiskQueueDepth10 次或更多），我们可以看到writeIOPS平均 300 次，而亚马逊仅提供100 次可靠的iOPS（来源）。

解决方案是每月为“配置的 iOPS”支付大约 200 美元。1000 是你能买到的最小的（这很容易覆盖我们）。在 350G 的存储上需要 5 个小时才能完成这项更改（但多可用区实例只有 30 秒的停机时间）之后，一切都很好，我们的 MySQL 5.6 实例运行得比原始 MySQL 5.5 实例更好，就像所有文献承诺的那样。

问题是我们迁移到 5.6 后得到的新 RDS 实例没有我们原来的那么好，这只是运气不好。我们询问了亚马逊支持“问：为什么 mysql5.5 与 mysql5.6 会有所不同？” 来自亚马逊：

您以前的底层主机可能已经从底层卷上异常少的使用中受益。您可能已经习惯了非常轻量级的使用，这让您可以消耗额外的 IOP 而不会累积太多DiskQueueDepth。但是，当您通过升级移动到新的底层主机时，您现在可能会遇到底层卷的更典型用法。对于基础卷的典型使用，不建议始终超过可靠 IOP 的数量，同时期望保持DiskQueueDepth您已经习惯的较低水平。但是，无法确认或否认这是原因。