MySQL高写入延迟

我正在开发一个类似社交的应用程序，该应用程序目前使用AWS服务进行部署。特别是，数据库使用MYSQL在RDS上运行。 到目前为止，我们正在使用数量有限的用户（主要是朋友）测试该应用程序，平均每秒写入IOPS为15

真正的问题是db的写入延迟非常高，总是超过100ms。RDS实例是一个db.m3.xlarge，比我们需要的多得多

我试图在一个单独的实例中执行负载测试（DB和EC2的配置相同），但我无法重现如此高的延迟，即使我发送的请求数量要高得多。所以我认为这可能是由于表碎片，但我还没有运行表优化，因为在此过程中无法访问数据库

你对这个问题有经验吗

更多信息

• 我们正在使用mysql版本5.6.21，其中INNODB作为存储引擎
• 整个数据库的大小约为100MB
• 最大的表（称为

  Message

  ）大约有790k行。关于这个表，下面的查询

  insert into Message (user_id, creationDate, talk_id, text, id) 
  values (2015, '2015-02-01 16:40:06.737', 18312, 'Some text ', 904870)
  

  执行了11秒

• 更糟糕的是，这个问题

  insert into Comment (anonymous, user_id, creationDate, deleted, post_id, text, id) 
  values (1, 107347, '2015-02-01 16:40:01.849', 0, 124888, 'Comment text', 265742)
  

  用了14秒，但表注释大约有160k

这两个表由以下内容生成：

CREATE TABLE `comment` (
    `id` bigint(20) NOT NULL,
    `anonymous` bit(1) NOT NULL,
    `creationDate` datetime NOT NULL,
    `deleted` bit(1) NOT NULL,
    `text` varchar(1000) COLLATE utf8mb4_unicode_ci NOT NULL,
    `user_id` bigint(20) NOT NULL,
    `post_id` bigint(20) NOT NULL,
    PRIMARY KEY (`id`),
    KEY `FK_jhvt6d9ap8gxv67ftrmshdfhj` (`user_id`),
    KEY `FK_apirq8ka64iidc18f3k6x5tc5` (`post_id`),
    CONSTRAINT `FK_apirq8ka64iidc18f3k6x5tc5` FOREIGN KEY (`post_id`) REFERENCES `post` (`id`),
    CONSTRAINT `FK_jhvt6d9ap8gxv67ftrmshdfhj` FOREIGN KEY (`user_id`) REFERENCES `kuser` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

及

一些绘图

使用我已经能够提取以下曲线图：

• 等待状态：查询结束时间不是太长了吗

• 页面缓冲区：

• 写入延迟和队列：

查询缓存

+------------------------------+-----------+
| Variable_name                | Value     |
+------------------------------+-----------+
| query_cache_limit            | 1048576   |
| query_cache_min_res_unit     | 4096      |
| query_cache_size             | 1048576   |
| query_cache_type             | OFF       |
| query_cache_wlock_invalidate | OFF       |
+------------------------------+-----------+

谢谢你的帮助

---

Andrea

您的查询配置文件显示“查询结束”时间非常长。这可能是由非常（太）大的压力引起的。每次执行update语句（INSERT、DELETE、update）时，都必须更新查询缓存（从更新的表读取的每个查询都无效）。

我与亚马逊的RDS工程师联系，他们给了我解决方案。 如此高的延迟是由于性能非常低的存储类型造成的。事实上，我使用的是默认的5GB SSD（他们称之为GP2），每GB存储提供3个IOPS，当我的应用程序需要大约50个IOPS甚至更多IOPS时，会产生15个IOPS

因此，他们建议我将存储类型更改为

Magnetic

，它提供100 IOPS作为基线。此外，我还能够减少实例类型，因为瓶颈只是磁盘

由于源磁盘（GP2）的性能非常低，迁移耗时约3小时

---

希望它能帮助其他人

我们需要更多的细节。您没有说明MySQL版本、存储引擎、数据库方案、数据大小、示例查询等。我们有非常高的写入系统，没有问题。谢谢您的回答Marcus。我添加了更多信息。我希望看到

id

为未签名和自动增量。您是如何生成ID的？我们使用Hibernate（JPA）来查询数据库。Hibernate为每个表保留最后使用的id并使用它插入新行MSYSQL一次分配4个扩展数据块（每个1mb）的空间。您的查询可以确保是MySQL时间，而不是其他时间。是的，它可能会变得支离破碎，尽管支离破碎只会影响读取大量连续记录，而不是搜索和选择最常见的单个记录。再次感谢！我检查了与查询缓存关联的变量（请参见问题），看起来缓存已禁用。我不知道每GB存储3 IOPS的规则。在谷歌上搜索如何确定我是否超过了限制，AWS支持人员说：“目前没有可用的指标来查看GP2 IO信用使用和余额。一种可接近的方法是监控DiskQueueDepth、ReadLatency和WriteRelatience等指标。如果您的RDS实例的IO点数不足，这些指标将上升。因此，如果您看到这些指标突然增加，并且一直保持在较高水平，则表明您的IO积分用完了。'来源：

+------------------------------+-----------+
| Variable_name                | Value     |
+------------------------------+-----------+
| query_cache_limit            | 1048576   |
| query_cache_min_res_unit     | 4096      |
| query_cache_size             | 1048576   |
| query_cache_type             | OFF       |
| query_cache_wlock_invalidate | OFF       |
+------------------------------+-----------+