大多数用户在对于磁盘进行分区的时候都是习惯性的不给系统盘预留很大空间，其实这并不是一个好习惯。因为系统分区并不像我们想象的那样会仅仅安装一个操作系统，系统分区多数还是会承载操作系统主要应用软件安装任务。那么当磁盘空间爆满后，MySQL会发生什么事呢？又应该怎么应对？
会发生什么事
当磁盘空间写满了之后，MySQL是无法再写入任何数据的，包括对表数据的写入，以及binlog、binlog-index等文件。
当然了，因为InnoDB是可以把脏数据先放在内存里，所以不会立刻表现出来无法写入，除非开启了binlog，写入请求才会被阻塞。
当MySQL检测到磁盘空间满了，它会怎么样呢？下面我们来看一个具体例子：
磁盘满了之后MySQL会做什么？
我们看下官方的说法
其实MySQL本身并不会做任何操作，如官方文档说说，只会每分钟check一次是否有空闲空间，并且10分钟写一次错误日志。
但是再次期间由于磁盘满了，意味着binlog无法更新，redolog也无法更新，所有bufferpool中的数据无法被flush上，如果不幸的服务器重启，或者实例被kill了，那必然会造成数据丢失，这几乎是一定的。所以，处理磁盘满的问题最好是先释放出来一定空间让dirty数据刷新下来。
磁盘满了为什么会导致操作hang住？
1、select
首先经过经验和实际测试，select操作不会由于磁盘满导致问题，也就是所有select操作都会正常运行。
2、insert
经过不通的测试发现，当磁盘满了之后，并不是第一个insert就卡住，而是会在n个之后出现卡住的情况。
通过查看error日志，发现卡住现象和刷磁盘的操作有关系。
为了验证推论是否正确，我们将sync_binlog设置为1，在这种情况下，insert第一条就卡住了，并且errorlog中直接报错提示写binlog失败。看来卡住确实和刷磁盘有关系。
目前已知和刷磁盘有关系的参数有3个，分别是sync_binlog，innodb_flush_log_tr_commit，和duoblewrite。
3、showslavestatus
在从库经过测试，操作会被卡住，这主要是由于执行showslavestatus需要获得LOCK_active_mi锁，然后锁上mi->data_lock，但是由于磁盘满了无法将io_thread中的数据写入到relaylog中，导致io_thread持有mi->data_lock锁，这就导致了死锁。
所以，这就导致在磁盘满的情况下，执行showslavestatus操作会卡住。
4、showstatus
测试可以正常操作，但是如果先执行了showslavestatus操作的情况下，showstatus也会被卡住。这是因为执行showstatus需要锁上LOCK_status，而由于status状态中包含slavestatus，所以还需要锁上LOCK_active_mi。如果限制性了showslavestatus，这时候由于mi->data_lock死锁问题，导致io_thread不会释放LOCK_active_mi锁。这时候就导致showstatus和showslavestatus争抢同一把LOCK_active_mi锁，也形成了死锁。
所以，在磁盘满的情况下，如果先执行showslavestatus，后执行showstatus，连个操作都会卡住。
应该怎么办
那么，当发现磁盘空间满了之后，我们应该怎么处理呢，建议：
每分钟：检查空间是否得到释放，以便写入新数据。当发现有剩余空间了，就会继续写入数据，一切照旧。
每十分钟：如果还是发现没剩余空间，则会在日志中写入一条记录，报告磁盘空间满(这时候只写入几个字节还是够的)。
提高监控系统检测频率，预防再次发生；
及时删除不用的文件，释放空间；
若有线程因磁盘满的问题被阻塞了，可先杀掉，等到下一分钟重新检测时它可能又可以正常工作了；
可能因磁盘满导致某些线程被阻塞，引发其他线程也被阻塞，可把导致阻塞的线程杀掉，其他被阻塞的线程也就能继续工作了。
例外
有个例外的情况是：
当执行REPAIRTABLE或者OPTIMIZETABLE操作时，或者执行完LOADDATAINFILE或ALTERTABLE之后批量更新索引时，这些操作会创建临时文件，当执行这些操作过程中mysqld发现磁盘空间满了，就会把这个涉及到的表标记为crashed，删掉临时文件(除了ALTERTABLE操作，MySQL会放弃正在执行的操作，删除临时文件，释放磁盘空间)。
备注：当执行这些命令过程中mysqld进程被意外被杀掉的话，其所生成临时文件不会自动删除，需要手工删掉才能释放磁盘空间。