1..以下所有讨论都基于mysql 5.5.37版本及官方文档，不保证适用于其他版本。
2.下文中提到的磁盘满，指的是数据文件（数据文件，日志文件，配置文件）所在磁盘分区。
3.由于篇幅问题，最后面的代码部分，只有关键的函数及逻辑判断部分。
1.如果主库上打开binlog，那么当磁盘满之后，每10分钟，
数据库会报告一条Disk is full writing './mysql-bin.000001' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)，
也就是说bin log写满了，等待磁盘空间，这与文档描述相同。
2，如果在主库上关闭binlog，当磁盘满了之后，任何插入行为都会失败，
报错为[ERROR] ./mysqld: The table 'x' is full，官方文档没有提到这个情况，此处的表x是innodb表。
上面是对主库所在磁盘写满之后，数据库实例的反应，下面讲讲我们遇到的情况：从库磁盘写满之后，show status及show slave status会被卡住，但其他select操作不受影响。

整个流程涉及3把锁：

1.mi->data_lock
2.LOCK_active_mi
3.LOCK_status

当一个新操作被接收到slave io线程后，如果这时候磁盘写满了，这个写入操作就会被阻塞，然后等待，直到磁盘有空间之后继续写入，这个操作中，会持有mi->data_lock锁，只有操作完成或者操作失败后，这个锁才会被释放，恰好，磁盘满不属于错误，于是操作阻塞，该线程会一直持有mi->data_lock锁。
当发起一个show slave status请求的时候，执行的时候，会首先锁住LOCK_active_mi锁，然后锁定mi->data_lock锁，当然，现在的情况下，mi->data_lock不会得到，于是LOCK_active_mi锁就会被该线程持续持有。
另外其一个会话发起show global status，执行的时候首先锁定LOCK_status锁，由于show status包括,Slave_heartbeat_period,Slave_open_temp_tables,Slave_received_heartbeats               ,Slave_retried_transactions这些状态，于是还需要LOCK_active_mi锁，于是，这个会话也会被阻塞掉。
之后如果再另外发起请求，由于LOCK_status已经被锁定，于是所有涉及show status的请求，都会被阻塞到这里。
之后所有show slave status请求也都会被阻塞在LOCK_active_mi锁处。
看了以上的结论，是否会想到另外一个操作顺序：
磁盘写满－>show status，
这种操作的结果是：
show status不会被阻塞的。

1..以下所有讨论都基于mysql 5.5.37版本及官方文档，不保证适用于其他版本。
2.下文中提到的磁盘满，指的是数据文件（数据文件，日志文件，配置文件）所在磁盘分区。
3.由于篇幅问题，最后面的代码部分，只有关键的函数及逻辑判断部分。
1.如果主库上打开binlog，那么当磁盘满之后，每10分钟，
数据库会报告一条Disk is full writing './mysql-bin.000001' (Errcode: 28). Waiting for someone to free space... (Expect up to 60 secs delay for server to continue after freeing disk space)，
也就是说bin log写满了，等待磁盘空间，这与文档描述相同。
2，如果在主库上关闭binlog，当磁盘满了之后，任何插入行为都会失败，
报错为[ERROR] ./mysqld: The table 'x' is full，官方文档没有提到这个情况，此处的表x是innodb表。
上面是对主库所在磁盘写满之后，数据库实例的反应，下面讲讲我们遇到的情况：从库磁盘写满之后，show status及show slave status会被卡住，但其他select操作不受影响。

整个流程涉及3把锁：

1.mi->data_lock
2.LOCK_active_mi
3.LOCK_status

当一个新操作被接收到slave io线程后，如果这时候磁盘写满了，这个写入操作就会被阻塞，然后等待，直到磁盘有空间之后继续写入，这个操作中，会持有mi->data_lock锁，只有操作完成或者操作失败后，这个锁才会被释放，恰好，磁盘满不属于错误，于是操作阻塞，该线程会一直持有mi->data_lock锁。
当发起一个show slave status请求的时候，执行的时候，会首先锁住LOCK_active_mi锁，然后锁定mi->data_lock锁，当然，现在的情况下，mi->data_lock不会得到，于是LOCK_active_mi锁就会被该线程持续持有。
另外其一个会话发起show global status，执行的时候首先锁定LOCK_status锁，由于show status包括,Slave_heartbeat_period,Slave_open_temp_tables,Slave_received_heartbeats               ,Slave_retried_transactions这些状态，于是还需要LOCK_active_mi锁，于是，这个会话也会被阻塞掉。
之后如果再另外发起请求，由于LOCK_status已经被锁定，于是所有涉及show status的请求，都会被阻塞到这里。
之后所有show slave status请求也都会被阻塞在LOCK_active_mi锁处。
看了以上的结论，是否会想到另外一个操作顺序：
磁盘写满－>show status，
这种操作的结果是：
show status不会被阻塞的。