日志文件：
RDS MySQL采用主从M-M的高可用架构，其主备之间的数据同步依靠binlog日志。为了减少binlog日志对用户的空间的占用，RDS会定时把日志备份到oss中， 然后将本地的binlog清除。当日志空间出现异常的时候，如下图，由于应用写入数据压力过大，导致binlog日志增加的速度大于了RDS上传到oss的速度， 造成了binlog日志增长迅猛，这时候需要用户对数据库进行优化，减小对数据库的变更操作。
曾经看到这样的案例，应用频繁的对表进行更新，但是在该表上有较多的大字段，由于在row格式下，binlog会记录整行记录， 这样就导致了binlog增长非常迅猛，详细可以参考Mysql大字段的频繁更新导致binlog暴增。所以在应用的设计初期，就要避免使用大字段：varchar(8000),text,blob,clob等。
还有一种情况可能是主备的复制卡主或者中断，则会导致主库的binlog没有传递到备库，那么这个时候binlog会一直在主库堆积， 那么就需要提工单要求尽快处理了。
临时文件：
临时文件通常可以理解为数据库做一个大的操作，由于内存不足，数据库需要将内存中的文件写到磁盘上，这样则有可能导致临时文件写的非常大， 通常出现这种情况的时候，数据库在做大的排序操作（order by，group by，distinct）。下图的案例中，由于数据库中一条order by的语句频繁的执行， 但是排序sql没有索引，导致了临时文件的频繁写操作：
当临时空间上涨原因是SQL排序导致的时候，可以通过show processlist快速找出排序的SQL，然后kill 掉SQL；
同时对排序的sql添加合适的索引，避免排序，这是治根的办法，避免数据库中出现排序的SQL；
为了避免排序消耗的空间过大，可以设置临时空间的大小，具体可以参考RDS参数优化loose_rds_max_tmp_disk_space
系统文件：
系统文件是每个数据库在安装的时候会初始化一些系统文件，这些系统文件是数据库正常运行的前提，mysql：ibdata1，ib_logfile0，下面的这幅图 反映了 “其他文件”占用达到了非常多的问题，可以参考：ibdata1文件持续增加的问题定位
1、ibdata1文件中大量的都是undo_log，建议将版本升级到5.6以上有独立的purge线程可以很快的回收掉undo log，可以单独设置undo tablespace 文件，避免与ibdata1混用在一起；
2、同时也可以采用逻辑迁移的方式，重建ibdata1文件；
3、数据库中要注意未提交的事务对undo的影响，监控数据库中的INNODB_TRX视图。
综上所述，空间问题也是一个比较复杂的问题，但是如果我们能够在系统设计之初遵循一些最佳实践，那么我们还是能够很好的处理掉这些问题， 祝你玩得开心，用得放心。
