监控目标必须是 datadir 挂载点而非 /var 或 /tmp；MySQL 崩溃报“No space left on device”但 df -h 显示 /var 有空间，说明 datadir 实际挂载在另一磁盘且已满；InnoDB redo log（ib_logfile0/1）写入失败导致事务卡死；须先查 SHOW VARIABLES LIKE 'datadir'，再用 df --output=source,pcent,target 确认对应挂载设备及使用率；阈值设为 85% 而非 95%，因 redo log 需空间做 checkpoint、刷脏页等；提取整数百分比应使用 df --output=pcent /path | tail -n1 | tr -d '% '，避免 df -h | grep 字段错位；脚本每分钟执行一次，≥85% 立即告警，告警含当前 df 输出和 mysqladmin ping 结果；仅可清理 slow_query_log 和 general_log，严禁动 ib_logfile*；binlog 清理靠 expire_logs_days 或 binlog_expire_logs_seconds 并 FLUSH LOGS；初始磁盘分配需按年增长预估 +30% 缓冲；Zabbix/Prometheus 应同时采集 df 使用率与 `INFORMATION_SCHEMA.INN
监控目标必须是 datadir 挂载点，不是 /var 或 /tmp
MySQL 崩溃时看到 No space left on device 或反复报 OS file read error，但 df -h 显示 /var 还有 20% 空间——大概率是 datadir 实际挂载在另一块盘（比如 /dev/sdb1），而那块盘已满。InnoDB 的 ib_logfile0 和 ib_logfile1 就放在 datadir 下，它写不进去，事务就卡死。
必须先查清真实路径：
mysql -e "SHOW VARIABLES LIKE 'datadir';"
再用 df --output=source,pcent,target 确认该路径对应的挂载设备和使用率。别只盯 /var 分区。
阈值设为 85%，而不是 95%
redo log 是循环覆写，但需要空间做 checkpoint、刷脏页、处理长事务。等磁盘用到 95%，MySQL 往往已经无法响应新写入请求。85% 是实测安全边界。
提取整数百分比更稳：
df --output=pcent /var/lib/mysql | tail -n1 | tr -d '% '
避免用 df -h | grep 解析，字段错位会导致误判。
- 脚本每分钟执行一次该命令，比定时扫描日志更及时
- 发现 ≥85% 后，立刻触发告警，不要等清理逻辑自动跑
- 告警内容必须包含当前
df输出和mysqladmin ping结果，确认实例是否已卡住
能删的只有 slow_query_log 和 general_log，千万别碰 ib_logfile
ib_logfile0 和 ib_logfile1 是 InnoDB 核心文件，删、mv、logrotate 都会导致启动失败，报错 InnoDB: The log sequence number in ibdata files does not match。
真正可安全清理的是文本类日志：
- 先确认是否启用：
SELECT @@slow_query_log, @@general_log; - 查路径：
SELECT @@slow_query_log_file, @@general_log_file; - 清理示例（保留最近 7 天）：
find /var/log/mysql/ -name "slow.log.*" -mtime +7 -delete
binlog 清理靠参数：expire_logs_days = 7 或 binlog_expire_logs_seconds = 604800，设置后需 FLUSH LOGS 生效。
监控要前置，不能依赖“快满了再扩容”
MySQL 对磁盘满极其敏感：写入阻塞、主从延迟突增、甚至整个实例 hang 死。等告警出来再操作，业务早就受影响了。
运维上必须做到：
- 初始分配空间按年增长预估 + 30% 缓冲（例如年增 200GB → 至少分 260GB）
- Zabbix/Prometheus 中同时采集
df使用率和INFORMATION_SCHEMA.INNODB_METRICS中的log_data_written，判断写入压力趋势 - 自动清理脚本只作用于归档日志和旧备份，绝不碰
datadir下的.ibd、ibdata1、ib_logfile*
最易被忽略的点：监控脚本和清理动作必须解耦。用信号或队列通知守护进程执行清理，避免 crontab 直接调用导致并发冲突——尤其在磁盘临界时，多个清理任务同时跑反而加重 I/O 压力。
