MySQL AWS RDS 实例大小意外地猛烈增长答案

【问题标题】：MySQL AWS RDS instance size grows violently and unexpectedlyMySQL AWS RDS 实例大小意外地猛烈增长
【发布时间】：2020-12-29 20:06:58
【问题描述】：

我一直在调查运行两个数据库的客户端 AWS RDS 实例 (MySQL 5.7.26) 中的一些奇怪行为。我不是数据库工程师，所以这超出了我的想象。

在一年中，RDS 实例大小在 2 小时内增加了 3 次。颠簸在1GB 到8GB 范围内。从角度来看，RDS 实例分配了60GB。 Here is a screenshot of the cloudwatch 记录这些事件之一。

两个数据库具有相同的架构，一个用于测试，另一个用于实时环境。它们都由一个时间序列数据的主表组成。这是架构：

SHOW CREATE TABLE timeSeriesTable;

'CREATE TABLE `timeSeriesTable` (
    `id` varchar(50) NOT NULL,
    `device_id` int(11) DEFAULT NULL,
    `timestamp` datetime DEFAULT NULL,
    `server_timestamp` int(11) DEFAULT NULL,
    `modified` int(11) DEFAULT NULL,
    `deleted` int(11) DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `sensor_id` (`sensor_id`),
      KEY `timestamp` (`timestamp`)
    )
ENGINE=InnoDB DEFAULT CHARSET=latin1'

活表统计如下：

column_count: 6
table_rows: 88749947
data_length: 5.8GB
index_length: 8.3GB

这里有很多可以优化的地方，但我目前主要关心的是避免将来出现类似的存储问题。其他说明：

当时主日志被禁用
RDS 性能洞察已禁用
表大小的总和证实了 AWS 存储估计（让我认为问题与数据相关或与 MySQL 相关）
数据进入系统有两种方式，一种是程序化的，另一种需要用户认证
不同时间块的行数一致，任何时间点都没有异常大量的数据
事件间隔不均匀，因此不是计划作业
我正在启用查询日志记录以潜在地捕捉到这一点

更新数据库重启后，可用存储空间神奇地增加了8GB。

【问题讨论】：

多少内存？ innodb_buffer_pool_size的设置是什么？我看到该表在磁盘上占用了大约 14GB。在峰值期间执行SELECTs 的位置？
我看到一个列 device_id，但在 sensor_id 上有一个索引。
@RickJames innodb_buffer_pool_size 读取：{DBInstanceClassMemory*3/4} 5242880-18446744073709551615，有一次我可以确认一个非常大的 SELECT 正在运行，RAM -> 16GB 和 sensor_id 和 device_id是一样的东西（我的坏）
改为运行SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
我添加到我的答案中。

标签： mysql amazon-web-services amazon-rds innodb

【解决方案1】：

我不能 100% 确定任何人都可以做任何事情来帮助解决这个问题。我有许多可能的建议，但我不确定它们中的任何一个是否能够仅通过 RDS 进行检查或验证：

是否手动创建了其他表？偶尔需要手动更改数据库时，我经常会在进行任何调整之前创建表的“备份”。
是否添加了其他索引？我无法确定索引是只占用内存还是存储空间，但我相信额外的索引会占用更多的存储空间，无论它们是否在内存中被积极使用。
您似乎只在看一张桌子。存储将受到数据库中的所有表以及实例上的其他数据库的影响。您确定是这个表导致了这个问题吗？

看起来确实很像当时正在将其他数据写入数据库。 IOPS、延迟和存储空间出现峰值。

您如何确定写入的数据量没有出现峰值？如果是查询共享，它可能会有所帮助。

我真的建议为此寻求专业支持。如果您没有接受过培训并且没有信心这样做，我绝对不建议您对数据库实例进行任何调查。

根据我的经验，跟踪数据库问题非常困难，如果不直接访问数据库并进行监控，我不确定是否有人能够有效地帮助您，而您可能很难在此处找到这些问题。

【讨论】：

【解决方案2】：

也许云服务正在备份？

您不想谈论优化，但这可能是解决方案，或者至少是其中的一部分。

INT 占用 4 个字节；考虑使用更小的数据类型。

id 中有什么内容？有什么好用的吗？如果没有，让我们讨论摆脱它；它在数据的 BTree 和两个二级索引的 BTree 中都很庞大。

如果(sensor_id, timestamp) 是唯一的，最好是PRIMARY KEY。（这是一个“复合”索引；顺序很重要。）这可能对SELECTs 的一些人有所帮助——提高性能以及它们需要加载到 RAM 中的多少才能执行。

我怀疑有一个SELECT 出现并扫描了整个桌子。在此之前，只有部分表在缓存（buffer_pool）中。这可以很容易地解释缓冲池增长时的峰值。 innodb_buffer_pool_size 有一个限制，但是，我猜它在达到峰值之前还没有扩展到完整大小。

innodb_buffer_pool_size 可能是 12GB。如果缓冲池还没有达到 12GB，那么对该传感器数据的表扫描会突然扩大缓冲池。这是正常的。

让我们看看那个大的SELECT，看看我们能不能让它不那么可怕。

【讨论】：