答案是检查错误日志中的“No space left on device”等关键词，并结合df -h、du -sh等系统命令排查磁盘使用情况。首先查看MySQL错误日志，定位“OS error code 28”、“disk full”或“Can't create/write to file”等报错，确认磁盘空间不足；然后通过SHOW VARIABLES命令查找log_error、slow_query_log_file等日志路径；接着分析二进制日志（Binlog）是否因expire_logs_days设置不当导致堆积；同时关注慢查询日志中IO性能下降的间接征兆；最后结合操作系统命令df -h和du -sh检查文件系统使用率及MySQL数据目录占用，配合iostat监控IO性能，设置监控告警预防问题。
MySQL排查磁盘空间不足，日志无疑是核心线索。我个人觉得，这就像医生诊断病情，日志就是病历和各种检查报告。最直接的当然是错误日志（error log），它会毫不留情地记录下“磁盘已满”之类的报错。但别忘了，慢查询日志（slow query log）有时也能提供间接的提示，比如查询突然变得异常缓慢，这可能是磁盘IO瓶颈的征兆，而IO瓶颈往往又和磁盘空间不足、文件碎片化脱不开关系。
解决方案
要通过日志排查MySQL磁盘空间不足，我通常会从几个关键日志入手，并结合系统层面的检查：
首先，错误日志（Error Log）是你的第一站。MySQL在遇到磁盘空间不足时，会直接在这里抛出错误。你需要仔细查看日志文件中是否有类似“No space left on device”、“disk full”或者“OS error code 28”这样的关键词。这些错误通常会伴随着MySQL尝试写入数据文件、创建临时文件、或者进行日志轮转时失败的记录。定位到这些错误的时间点，然后去检查那个时间点的系统磁盘使用情况，基本就能锁定问题了。
接着，二进制日志（Binary Log，或称Binlog）也是一个常见的“大胃王”。我的经验是，很多时候磁盘空间被悄悄吃掉，都是因为Binlog文件累积过多。如果你的
expire_logs_days参数设置不合理（比如设置得太大或者根本没设），或者系统负载高导致Binlog生成速度快，那Binlog文件很快就能填满你的磁盘。检查Binlog文件的大小和数量，对比你的保留策略，这通常能发现一些问题。
然后是慢查询日志（Slow Query Log）。虽然它不直接报告磁盘空间不足，但如果发现某个时间段内慢查询数量激增，或者平时很快的查询突然变得非常慢，这可能间接说明了磁盘IO性能下降。而磁盘IO性能下降，有时就是因为磁盘空间快满了，导致文件碎片化严重，或者操作系统在管理文件时效率降低。这需要你结合错误日志和系统监控来看，形成一个完整的判断。
最后，别忘了临时文件（Temporary Files）。MySQL在执行一些复杂查询（如
ORDER BY、
GROUP BY、
DISTINCT、大表连接）时，会生成大量的临时表和临时文件。这些文件通常在
/tmp目录或者MySQL配置的
tmpdir目录下。如果这些目录所在的文件系统空间不足，也会导致MySQL报错。虽然不直接体现在MySQL日志中，但错误日志可能会提示“Can't create/write to file”并指向一个临时文件路径。
如何快速定位MySQL的错误日志和慢查询日志？
定位MySQL的日志文件，其实有几种很直接的方法，我通常会交叉使用来确保准确性。毕竟，配置文件的位置和日志的实际路径有时候会有出入，或者你面对的是一个别人搭建的环境。
最权威的当然是查看MySQL的配置文件my.cnf
或my.ini
。这些文件通常位于
/etc/my.cnf、
/etc/mysql/my.cnf、
/usr/local/mysql/etc/my.cnf或Windows下的MySQL安装目录。在配置文件中，你可以找到类似
log_error = /var/log/mysql/error.log和
slow_query_log_file = /var/log/mysql/mysql-slow.log的配置项。这是最直接的答案。
但如果配置文件不好找，或者你不确定哪个配置文件是生效的，你可以直接登录到MySQL客户端，通过SQL命令查询：
SHOW VARIABLES LIKE 'log_error'; SHOW VARIABLES LIKE 'slow_query_log_file'; SHOW VARIABLES LIKE 'datadir'; -- 这个也很重要，很多日志默认在数据目录下 SHOW VARIABLES LIKE 'general_log_file'; -- 如果启用了通用查询日志 SHOW VARIABLES LIKE 'log_bin_basename'; -- 定位二进制日志的基础文件名
这些命令会告诉你当前MySQL实例正在使用的日志文件的完整路径。这几乎是最保险的方法。
一旦你确定了日志文件的路径，就可以使用操作系统级别的命令来查看它们了，比如：
# 查看错误日志的最新内容 tail -f /var/log/mysql/error.log # 搜索错误日志中包含“space”的行 grep -i "space" /var/log/mysql/error.log # 查看慢查询日志的最新内容（可能需要sudo权限） tail -f /var/log/mysql/mysql-slow.log
通过这些方法，你就能快速、准确地找到你需要的日志文件，为接下来的排查工作打下基础。
错误日志中出现哪些关键词提示磁盘空间不足？
在我的实际操作中，当MySQL因为磁盘空间不足而“罢工”时，错误日志里那些“刺眼”的关键词，就像是系统在向你大声呼救。以下是一些我经常会遇到的，直接或间接指向磁盘空间问题的关键词：
-
No space left on device
: 这是最直接、最明确的提示。它几乎可以肯定地告诉你，MySQL尝试写入文件（无论是数据文件、日志文件还是临时文件）时，操作系统返回了没有可用空间的错误。 -
OS error code 28
: 这个错误码在Linux系统中尤其常见，它就是“No space left on device”的操作系统错误代码表示。看到这个，基本上就可以确认是磁盘满了。 -
disk full
: 有时，错误信息会更口语化一些，直接就写“disk full”。意思和“No space left on device”一样。 -
Can't create/write to file
: 这种错误通常会跟着一个具体的文件路径，比如Can't create/write to file '/var/lib/mysql/mydb/mytable.ibd'
或者/tmp/#sql_xxxx.MAI
。这意味着MySQL无法在指定位置创建或写入文件，很可能是因为该文件系统已经没有空间了。这对于定位是哪个文件系统（比如是数据目录，还是/tmp
）出了问题非常有帮助。 -
Failed to write to file
: 类似Can't create/write to file
，也是写入操作失败的提示。 -
Error writing file
: 同样是写入失败的通用错误。
当你看到这些关键词时，第一反应就应该是立即检查服务器的磁盘使用情况，使用
df -h命令查看各个挂载点的剩余空间，然后用
du -sh /path/to/mysql/data来检查MySQL数据目录的实际占用。同时，注意错误日志中记录的时间戳，这能帮你精确到问题发生的时间点，去比对当时的系统监控数据，或者回溯当时是否有大操作在进行。
除了日志，还有哪些方法可以监控和预防MySQL磁盘空间不足？
仅仅依靠日志来排查问题，往往是亡羊补牢。我个人更倾向于主动监控和预防，这样才能避免突发状况。除了日志，我们还有很多方法可以用来监控和预防MySQL磁盘空间不足：
1. 操作系统级别的监控： 这是最基础也最关键的。
-
df -h
: 定期查看所有文件系统的空间使用率。我通常会设置一个阈值，比如80%或90%，一旦超过就触发告警。 -
du -sh /path/to/mysql
: 深入到MySQL的数据目录，查看具体是哪个子目录（data
、binlog
、relaylog
等）占用了大量空间。这能帮你快速锁定是数据文件增长过快、还是日志文件堆积。 -
iostat
/sar
: 监控磁盘IO性能。虽然不直接显示空间，但IO性能的突然下降往往是磁盘空间不足、碎片化或硬件故障的前兆。
2. MySQL内部信息查询： 利用MySQL自身提供的视图和命令来了解存储情况。
-
SHOW TABLE STATUS FROM database_name;
: 可以查看每个表的数据大小、索引大小等信息。 -
SELECT table_schema, table_name, data_length + index_length FROM information_schema.tables ORDER BY (data_length + index_length) DESC;
: 更详细地列出所有数据库中表的大小，方便找出“大表”。 -
SHOW BINARY LOGS;
: 查看当前的二进制日志文件列表和大小。结合SHOW VARIABLES LIKE 'expire_logs_days';
可以评估Binlog的清理策略是否合理。
3. 配置参数优化与调整： 很多时候，磁盘空间不足是由于MySQL的配置不当造成的。
-
expire_logs_days
: 合理设置二进制日志的保留天数，这是清理Binlog最直接的手段。 -
max_binlog_size
: 控制单个Binlog文件的大小，避免单个文件过大。 -
innodb_log_file_size
/innodb_log_files_in_group
: InnoDB重做日志文件的大小和数量。虽然不直接影响数据文件，但过大的重做日志会占用固定空间，且在崩溃恢复时影响性能。 -
tmpdir
: 确保临时文件目录有足够的空间，并且最好是独立的、高性能的磁盘。
4. 定期清理与维护： 主动清理不必要的文件。
-
PURGE BINARY LOGS TO 'mysql-bin.XXXXXX';
或PURGE BINARY LOGS BEFORE 'YYYY-MM-DD HH:MM:SS';
: 手动清理过期的二进制日志。 -
优化表（
OPTIMIZE TABLE
）: 对于InnoDB表，这通常是重建表，可以回收碎片空间，但会占用临时空间。对于MyISAM表效果更明显。 - 删除不再使用的数据库或表: 这是最直接的回收空间方式。
- 清理不再需要的旧备份: 备份文件往往是巨大的。
5. 专业的监控工具集成： 将上述监控指标集成到专业的监控系统（如Prometheus + Grafana, Zabbix, Nagios等）。
- 配置告警规则，当磁盘使用率、Binlog增长速度、慢查询数量等指标达到预设阈值时，及时通知DBA。
- 通过历史数据趋势图，预测磁盘空间何时会耗尽，从而提前进行容量规划。
通过这些多维度的监控和预防措施，我们就能在磁盘空间成为瓶颈之前，发现问题并采取行动，而不是等到MySQL报错才开始手忙脚乱地排查。
