1. RDS空间使用率一直在飙升，是什么问题？
有以下几种可能性：
(1)临时空间快速增长
一些查询语句(order by, group by)会创建临时表。用explain查看select语句的执行计划，如果extra列显示“using temporary”,即使用了内部临时表。使用临时表一般都意味着性能比较低，在实际应用中应该尽量避免临时表的使用。常见的方法有：
a. 创建索引：在ORDER BY或者GROUP BY的列上创建索引；
b. 分拆很长的列：一般情况下，TEXT、BLOB，大于512字节的字符串，基本上都是为了显示信息，而不会用于查询条件， 因此表设计的时候，应该将这些列独立到另外一张表。
如果表的设计已经确定，修改比较困难，那么也可以通过优化SQL语句来减少临时表的大小，以提升SQL执行效率。
(2)日志文件快速增长
DDL/DML语句过多，导致binlog快速产生。用户可以一键清除所有的BINLOG文件，清除的BINLOG文件会被上传至阿里云开放存储服务OSS。如果用户清除了BINLOG日志，则不能按时间点创建临时实例。
可参考：几招省磁盘空间的方法
2. 没有进行修改权限的操作，RDS实例突然无法执行insert、update、delete操作，是什么原因？
实例使用的磁盘空间超过了所购买的最大磁盘容量时，RDS实例会被系统锁定。实例被锁定后，用户只有select、show view和drop table的权限，无法进行insert、update、delete等操作。出现这种情况后，建议用户尽快升级实例配置购买磁盘容量，磁盘容量足够时系统会自动解锁实例。
3. 大字段会导致SQLSERVER日志空间占用快速上升
在SQL Server中用varchar(max)/nvarchar(max)、varbinary(max)、text/ntext、image这些大字段，可能导致数据库日志飚升，达到或超过数据文件大小，导致实例被锁定。实际案例中，有的客户1小时增长超过100G。经过改进，将大部分字段调小，该问题消除。
建议：
除了历史归档或文献资料类型的应用外，一般不需要用大字段来做存储。大字段的最大存储大小是 2^31-1 个字节 (2 GB)，所以SQL Server需要用一种特别的方式来存储和操作它，其成本也就比普通字段高。而如果数据库使用了full模式，响应的日志量也就高很多了。
4. 刚买的MySQL新实例，还没开始用，怎么磁盘空间就消耗很多了？
初始化后系统文件会占用一定空间，包括ibdata1和relog文件。
ibdata1：系统共享表空间文件，主要用于存储数据字典、undo entry、insert buffer、doublewrite buffer，默认为200M(innodb_data_file_path=ibdata1:200M:autoextend)
relog 文件：logfile0、logfile1 是循环使用，不会收缩的。
5. 问题：实例空间暴涨导致锁定
处理：排查发现两方面原因导致实例空间锁定，一个是binlog问题，我们没能及时备份上传导致binlog有一定累计，占用了用户的空间；还有一个是sql问题，查看性能数据发现在导致空间锁定期间实例的其它数据空间有明显的上涨，而我们抓取的其它空间主要是ibdata和ib_logfile文件还有查询会使用的临时空间，对比ibdata和ib_logfile文件前后并未发生变化，推断应该是存在范围较大的排序、聚合操作导致实例空间暴涨。
6. 为什么我本地的数据库，导入到RDS后空间消耗变多了？
a.导入数据后，是有大量日志产生。如果没有达到RDS的保留期限，是不会删除的，可以建议客户手工清理日志。
b.数据文件的扩展占用空间。InnoDB的数据组织是16KB的页面，可能会有一些空间浪费，特别是删除和更新较多的时候。
7. 用户的ibdata1文件持续增加，4G的空间被ibdata1 被这个文件占用了，这是如何造成的？
Innodb的表有两种存放方式：
第一种共享表空间方式：所有表的索引，数据统一存放在一个共享表空间中，这样会导致共享表空间的空间迅速增长，同时空间回收困难；
第二种独占表空间方式：就是RDS目前采用的，也就是一张表一个表空间，表中的索引和数据存放在自己独立的表空间中，空间能够比较容易的回收。
无论是独占还是共享表空间，innodb都会有系统共享表空间(ibdata1)，该系统表空间主要用于存储数据字典，undo entry，insert buffer，doublewrite buffer。
ibdata1的增加通常的原因有如下：
a. 长时间没有提交事务，同时数据库中有大量的更新、插入、删除，导致innodb创建大量的undo来维护一致性读；
b. mysql 5.1中undo的purge是和master thread 共用一个线程，所以发现show engine inndob status\G中的history length过长，则可能的purge的速度到达了瓶颈，所以在mysql 5.5将undo的purge独立出来，可以设置undo purge的线程个数。
ibdata1文件中大量的都是undo_log，我们可以采取以下方案：
建议用户将版本从5.1升级到5.5，5.5中有独立的purge线程可以很快的回收掉undo log,迁移的过程中由于是采用逻辑迁移，会重建ibdata1文件降低空间使用；
在5.6中可以单独设置undo tablespace文件，避免与ibdata1混用在一起。