RDS MySQL 5.6故障案例
我们公司生产业务中，存在一张大表，240G左右，共有七千多万行，而且呈每天1G多的增长量在增加，而RDS的磁盘一共有500G，现在还剩下80G左右，所以目前的解决方案是，每隔一段时间就删除一些表上的数据，因为这张大表是类似日志形式的，很少会有读操作
这天晚上我执行了几条delete语句，删除了大概有二三百条的数据，我本以为这样就可以了，去查询了一下磁盘空间，丝毫没有改变，去百度了一下：
在MySQL中有这样一种机制，当你删除了表中内容后，空间不是马上释放出来的，你删除的等于抹除了这个行上的数据内容，但是位置还是在的，所有空间依然被占用中，当你下次insert操作时，它会自动补到这个位置上，所以对于innodb的存储引擎而言（myisam暂时不清楚）要想马上把磁盘空间释放出来的话要执行优化表的操作：
optimize table 加上表名，但是在执行优化表的操作时，有很重要的一点就是，MySQL会进行锁表，并且建立一张与优化表相同的临时表，等待临时表创建完毕，才会删除旧表，并释放占用的磁盘空间
当我开心的执行优化表的操作后，我傻了
IO直线上涨，更可怕的是磁盘空间在不断增加，根本停不下来，我担心磁盘撑爆以后MySQL就该宕机了，然后向阿里云的人进行咨询，他们说可能因为表太大了，所以执行时间太慢了，可以在等待一段时间或者主动把这个优化表的进程kill掉就可以恢复了
此时磁盘空间已经涨到了800G+，我很纳闷，我的RDS明明只有500，为什么他还可以用？而且现在数据库的访问还是正常的，来不及多想，已经三个多小时过去了，跟领导请示之后，允许kill进程，然后我去执行后，20分钟左右，磁盘空间恢复了，一切正常
总结：
1. 如果这是物理服务器，估计必宕无疑，因为物理机可没有弹性伸缩这个说法，所以MySQL跑在物理机上的伙伴执行优化表的操作要充分考虑磁盘空间的问题
2. 优化表不是每次删除之后都建议去执行，特别大的表建议每一个月或者半个月左右去执行一次，而且肯定是要选择在业务的低峰期进行操作
3. 通过这次故障后，我把原本在云上备份的数据，又拉到本地服务器一份，充分对数据做好冗余方案