一、磁盘满了之后MySQL会做什么？
创新互联服务项目包括兴城网站建设、兴城网站制作、兴城网页制作以及兴城网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，兴城网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到兴城省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！
我们看下官方的说法：
When a disk-full condition occurs, MySQL does the following:
* It checks once every minute to see whether there is enough space to write the current row. If there is enough space,it continues as if nothing had happened.
* Every 10 minutes it writes an entry to the log file, warning about the disk-full condition.
其实MySQL本身并不会做任何操作，如官方文档说说，只会每分钟check一次是否有空闲空间，并且10分钟写一次错误日志。
但是再次期间由于磁盘满了，意味着binlog无法更新，redo log也无法更新，所有buffer
pool中的数据无法被flush上，如果不幸的服务器重启，或者实例被kill了，那必然会造成数据丢失，这几乎是一定的。所以，处理磁盘满的问题最好是先释放出来一定空间让dirty数据刷新下来。
二、磁盘满了为什么会导致操作hang住？
1、select
首先经过经验和实际测试，select操作不会由于磁盘满导致问题，也就是所有select操作都会正常运行。
2、insert
经过不通的测试发现，当磁盘满了之后，并不是第一个insert就卡住，而是会在n个之后出现卡住的情况。
通过查看error日志，发现卡住现象和刷磁盘的操作有关系。
[ERROR] /usr/local/mysql-5.1.42/libexec/mysqld: Disk is full writing './test/cj_webex.MYD'
[ERROR] /usr/local/mysql-5.1.42/libexec/mysqld: Disk is full writing './mysql-bin.000017'
为了验证推论是否正确，我们将sync_binlog设置为1，在这种情况下，insert第一条就卡住了，并且error
log中直接报错提示写binlog失败。看来卡住确实和刷磁盘有关系。
目前已知和刷磁盘有关系的参数有3个，分别是sync_binlog，innodb_flush_log_tr_commit和duoblewrite。
3、show slave status
在从库经过测试，操作会被卡住，这主要是由于执行show slave
status需要获得LOCK_active_mi锁，然后锁上mi-data_lock，但是由于磁盘满了无法将io_thread中的数据写入到relay
log中，导致io_thread持有mi-data_lock锁，这就导致了死锁。
所以，这就导致在磁盘满的情况下，执行show slave status操作会卡住。
4、show status
测试可以正常操作，但是如果先执行了show slave status操作的情况下，show
status也会被卡住。这是因为执行show status需要锁上LOCK_status，而由于status状态中包含slave
status，所以还需要锁上LOCK_active_mi。如果限制性了show slave
status，这时候由于mi-data_lock死锁问题，导致io_thread不会释放LOCK_active_mi锁。这时候就导致show
status和show slave status争抢同一把LOCK_active_mi锁，也形成了死锁。
所以，在磁盘满的情况下，如果先执行show slave status，后执行show status，连个操作都会卡住。
生产环境中，MySQL 不经意间吃掉全部的内容，然后开始吃掉 SWAP，性能一降再降，怎么办？
可以从下面三点查看原因：
MySQL 使用内存，有两个途径。
永久占用的内容
比如全局缓冲区（Global Buffer）类别，是在服务器启动期间从操作系统获得的，不会释放到任何一个别的进程。
动态请求的内存
线程缓冲区由MySQL使用，它是在处理新查询时从操作系统请求的内存。在执行查询之后，该内存被释放回操作系统。
这意味着 MySQL 的内存使用，是 全局缓冲区 加上 线程缓冲区 以及 允许的最大连接数 。
对于专用数据库服务器，该值需要保持在服务器内存的90%以下。在共享服务器的情况下，它应该保持在服务器内存的50%以下。
检查一下 MySQL 设置，有助于确定内存使用情况，从而为 MySQL 分配合适的值。
一个近似的公式：
当网站受到攻击时，有可能在短时间内建立异常高的连接数量。MySQL 中的 PROCESSLIST 可用于检测顶级用户并阻止对滥用连接的访问。
找出查询需要很长时间才能执行的语句，因为这些查询需要进一步优化服务器才能更好地执行，可以通过服务器查询日志进行识别。由于查询速度慢，导致磁盘读取较多，导致内存和CPU使用率较高，影响服务器性能。
最后，到了加内存条的时候了。虽然在优化数据库设置之后，服务器会不断地路由到使用交换内存，但也必须增加内存。俗话说：“巧妇难为无米之炊”，就是这个意思。
上面说的这些方向，大家可以在实际操作中验证体会，希望大家在数据库优化的路上，麻溜顺畅，砥砺前行。
在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中，有一个环节是人为制造磁盘满的场景，看看MGR是否还能正常响应请求。
在实测过程中，最后发现磁盘满的那个节点，持续时间足够久后，会因为内存消耗过大而最终被OS给OOM Kill。
这个问题我已报告BUG（#104979），下面是该过程的详细记录。
首先，直接利用dd复制空文件填满磁盘。
disk full报告过程及何时被oom killed
来看下MySQL 8.0.26遇到disk full时日志都输出哪些内容：
从disk full时刻开始，大约过了2.5小时，mysqld进程内存消耗持续上升，最终引发oom kill
在这期间某个时刻抓到的待认证事务堆积，在被oom kill前实际不止这么多：
关注mysqld进程内存消耗变化
下面是mysqld进程内存消耗变化情况
OS层oom-killer相关日志：
GreatSQL 8.0.25测试过程
作为对比，我用GreatSQL 8.0.25也做了同样的测试。
从日志详情中可以看到，当磁盘空间满了之后，GreatSQL会将那个节点主动退出集群，对整个集群的影响非常小。
此外，从集群退出后，也不会再接收认证事务了，所以也没发生内存持续暴涨最终被oom killed的情况，实际观察过程中发现内存反倒还下降了
这样对比来看，GreatSQL的可靠性还真是可以的，官方的MySQL MGR的可靠性还有待进一步加强呀。
Enjoy GreatSQL :)
可以通过查看mysql进程来实现。 进入mysql命令行客户端，选择数据库后，执行show processlist命令： 多刷新几次，可以看到最后执行的SQL语句，以此判断什么查询在占用资源。
