MySQL 实例空间使用率过高的原因和解决方法

用户在使用 MySQL 实例时，会遇到空间使用告警甚至超过实例限额被锁定的情况。在 RDS 控制台的实例基本信息中，即会出现如下信息：

本文将介绍造成空间使用率过高的常见原因及其相应的解决方法。对于MySQL 5.6版本的实例，升级实例规格和存储空间后即可解锁实例，关于如何升级实例配置，请参见变更配置。

常见原因

造成 MySQL 实例空间使用率过高，主要有如下四种原因：

Binlog 文件占用高。
数据文件占用高。
临时文件占用高。
系统文件占用高。

查看空间使用状况

您可以通过 DMS 中的诊断报告来查看实例空间的使用情况。

在 DMS 控制台上登录数据库。
选择性能 > 诊断报告。
单击发起诊断，即可创建一个针对当前实例运行情况的报告，如下图所示：
单击查看报告，即可在诊断报告中查看到实例空间使用情况，如下图所示：

图示说明：
- ins_size：实例整体空间。
- other_size：系统文件和临时文件使用空间。
- data_size：数据文件使用空间。
- binlog_size - Binlog：文件占用空间。

解决方法

升级实例规格

升级实例规格是解决空间问题的有效方式之一。目前，RDS已支持独占物理机规格的实例，最大存储空间可达到3T。建议您将实例规格升级至独占物理机，关于独占物理机实例的计费详情，请参见云数据库RDS详细价格信息，升级实例规格的操作步骤如下。

登录RDS管理控制台。
选择目标实例所在地域。
单击目标实例的ID，进入基本信息页面。
在配置信息栏中，单击变更配置。

说明：若是包年包月实例，请再单击立即升级配置或者续费降配/续费升配。
在变更实例页面，将实例规格变更为独占物理机，并选择较大的存储空间，如下图所示。
单击确认变更。

其它方法

本章节将介绍在不升级实例规格的情况下解决空间问题的方法。

Binlog 文件占用高的解决方法

Binlog 文件记录实例的事务信息，是 MySQL 实例 HA 架构以及高可用性、可恢复性的基础，是不可以关闭的。

RDS 实例会以一定时间间隔自动清理（上传到 OSS 并从实例空间中删除）最近 18 小时外的 Binlog 文件。如果短时间内实例 DML 操作生成了大量 Binlog 数据，有可能会导致超过实例磁盘空间上限而被锁定。

在这种情况下，可以通过 RDS 控制台来清理（将 Binlog 文件上传到 OSS 并从实例空间中删除）Binlog 数据。

操作步骤

登录 RDS 管理控制台。
选择目标实例所在地域。
单击目标实例的 ID，进入基本信息页面。
选择左侧菜单栏中的备份恢复。
单击一键上传 Binlog。
说明：
- 一键上传 Binlog 会在后台异步提交清理任务，因此单击后会很快返回。清理任务会先将完成写入的 Binlog 上传到 RDS 的 OSS （非用户购买的 OSS）上，然后再从实例空间中删除 Binlog 文件，当前正在被写入的 Binlog 文件由于未完成写入，是不可以被清理的。因此，清理过程会有一定延迟，建议您单击后耐心等待一定时间，请勿多次单击该按钮。
- 对于由于 DML 等操作（比如涉及大字段的 DML 操作）导致快速生成 Binlog 的情况，可能会出现多次单击一键上传 Binlog 按钮但 Binlog 空间占有率依旧上涨的情况，这是因为上传 Binlog 文件到备份空间并且从实例空间中删除的处理速度跟不上实例生成 Binlog 文件的速度，在这种情况下，建议考虑升级磁盘空间，并且排查 Binlog 快速生成的原因。

数据文件占用高的解决方法

对于数据文件占用空间高的情况，可以通过清理数据的方式来减少空间占用情况，比如通过 drop table 和 truncate table 命令来清理不再需要的数据。

另外，下面是两种用户常用于清除空间内数据文件的方法，但实际并为达到预期效果，原因及解决方法如下所示：

用 delete 操作删除数据

delete 操作不能够直接回收被删除数据占用的数据文件空间，这就好比排空泳池中的水但泳池的占地面积不会发生改变一样。

在用 delete 操作删除数据后，需要通过 optimize table tab_name; 操作来回收空间，详情请参见 RDS for MySQL 删除数据后显示空间没有减少。
删除备份

RDS 备份是放置在后台 OSS 上，不占用用户的 RDS 实例空间，因此删除备份不能解决实例的空间问题。而且删除备份会影响实例的可恢复性，强烈建议在任何情况下都不要考虑删除备份。

数据文件占用空间的查询方法

方法一：

数据文件在频繁的 DML 后会出现数据空洞的现象，通过如下查询获取的数据文件占用的空间比较接近实际数据文件占用空间的计算方式：

select sum(data_length + index_length + data_free) / 1024 / 1024 from information_schema.tables;

方法二：

information_schema.tables 提供的是根据采样获取的表的部分统计信息，因此通过如下查询获取的表、库数据尺寸和实际数据文件占用尺寸间会有出入（通常要小于实际数据文件占用空间）。

说明：因为 information_schema.tables 中提供的是采样统计数据，因此该计算方式在统计数据比较接近实际的情况下，才会比较接近真实空间占用情况。

select table_name, concat(round((data_length + index_length) / 1024 / 1024,2),’MB’)from information_schema.tableswhere table_schema = ‘rd_test’and table_name = ‘large_tab_01’;

查询结果如下图所示：

从上图可以看出，在收集表的统计信息前后反馈出的表数据量大小存在差异。即使通过 analyze table 命令重新收集统计信息，得到的数值通常也小于实际数据文件占用空间，例如本例的 16143 MB 也小于该表的数据文件实际占用的空间。

临时文件占用高的解决方法

临时文件会随查询的结束或者会话的终止而自动释放，因此如果是临时文件导致实例空间满而锁定，可以通过终止会话来释放空间。

关于如何终止会话，请参见 RDS for MySQL 如何终止会话。

关于临时文件的常见问题，请参见 RDS for MySQL the table ‘/home/mysql/xxxx/xxxx/#tab_name’ is full 的原因和处理。

https://help.aliyun.com/knowledge_detail/51682.html

系统文件占用高的解决方法

系统文件涉及到 ibdata1 系统表的空间文件和 ib_logfile0、ib_logfile1 日志文件。

ibdata1 文件

InnoDB 引擎表由于支持多版本并发控制（MVCC），因此会将查询所需的 Undo 信息保存在系统文件 ibdata1 中。

如果存在对一个 InnoDB 表长时间不结束的查询，而且在查询过程中表有大量的数据变化，则会生成大量的 Undo 信息，导致 ibdata1 文件尺寸增加。由于 MySQL 内部机制的限制，ibdata1 文件目前是不支持收缩的。

因此，若出现这种情况，在不升级磁盘空间的前提下，比较好的解决方法是在同地域同可用区购买相同配置的 RDS 实例，通过 DTS 工具将数据迁移到新实例中。

建议您监控和清理执行时间过长的会话或事务，详情请参见 RDS MySQL 管理长时间运行查询。

ib_logfile 日志文件

ib_logfile0 和 ib_logfile1 日志文件保存 InnoDB 引擎表的事务日志信息，其文件大小尺寸固定，不可以改变。较大的尺寸在高并发事务的场景下有利于减少事务日志文件切换的次数，提高实例性能。