升级后ibdata1和binlog最易“膨胀”：前者因innodb_file_per_table=OFF导致删表不释放空间，后者因binlog_expire_logs_seconds未配置而持续堆积；需用du脚本+mysqld_exporter监控物理占用并分层预警。
查清升级后哪些文件会突然“膨胀”
MySQL 8.0+ 升级后，ibdata1 不再默认承担系统表空间（除非你显式设了 innodb_system_tablespace_file_per_table=OFF），但很多老实例仍保留 innodb_file_per_table=OFF 配置——这时所有表数据都挤进 ibdata1，删表、清数据完全不释放磁盘空间。你看到磁盘没降反升，大概率是它在默默吃空间。
二进制日志也容易被忽略：log_bin 默认开启，且 expire_logs_days 在 MySQL 8.0.33+ 已被标记为 deprecated，改用 binlog_expire_logs_seconds；如果没配或配错，/var/lib/mysql/mysql-bin.* 可能堆积数月未清理。
- 立即执行：
SHOW VARIABLES LIKE 'innodb_file_per_table';—— 若为OFF，ibdata1就是定时炸弹 - 确认 binlog 清理策略：
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';，若返回0或空值，表示永不清除 - 检查 relay log（尤其从库）：
SHOW VARIABLES LIKE 'relay_log_purge';，OFF时relay-log.info和对应文件会持续增长
用 du + 定时脚本盯死关键目录
MySQL 内部视图（如 INFORMATION_SCHEMA.FILES）只反映表逻辑大小，不等于磁盘占用；真正要监控的，是操作系统层面的物理路径。升级后目录结构可能微调（比如 8.0 引入 mysql.ibd 系统表空间文件），必须按实际路径扫。
别依赖单次 du -sh，要固化成可告警的采集逻辑：
- 核心路径优先级：
/var/lib/mysql/（总览）、/var/lib/mysql/mysql-bin.*（binlog）、/var/lib/mysql/relay-log*（中继日志）、/var/lib/mysql/ibdata1（共享表空间） - 写个简单脚本（例如
/usr/local/bin/mysql-disk-check.sh），用du -sb获取字节数（避免-h的单位歧义），输出格式如：binlog_bytes 1234567890 - 配合
systemd timer或cron每 5 分钟跑一次，把结果写入临时文件或直接发到监控端点
用 Prometheus + mysqld_exporter 抓真实指标
mysqld_exporter 0.15.0+ 版本才完整支持 MySQL 8.0 的新状态变量（如 mysql_global_status_innodb_data_pending_fsyncs），旧版本连 ibdata1 大小都报不准。升级 MySQL 后，务必同步升级 exporter，否则监控就是“假安全”。
关键指标不是看“用了多少”，而是看“还在涨不涨”：
-
mysql_global_status_innodb_data_file_bytes：反映ibdata1实际大小，注意它不含.ibd文件（那些走mysql_info_schema_table_size_bytes） -
mysql_global_status_binlog_bytes：需确认 exporter 启动时加了--collect.binlog参数，否则该指标恒为 0 -
mysql_global_status_created_tmp_disk_tables持续上升？说明tmp_table_size或max_heap_table_size设置过小，频繁落盘生成临时文件，间接加剧磁盘压力
设置空间预警的两个硬门槛
磁盘预警不能只设“剩余 10% 告警”这种笼统规则——MySQL 的写入行为有突发性，尤其是大事务提交、DDL 执行、或者 OPTIMIZE TABLE 操作，可能几分钟内吃掉几十 GB。必须分层设防。
- 第一道防线（紧急）：当
/var/lib/mysql/所在分区使用率 ≥ 85%，立刻触发一级告警（电话/钉钉强提醒），此时已无缓冲余量 - 第二道防线（观察）：监控
binlog_expire_logs_seconds对应的实际日志体积周环比涨幅 > 300%，或ibdata1日增量 > 2GB，说明业务写入模式突变，需人工介入排查 - 切记：不要对
ibdata1做自动清理——它不可收缩，任何“清空重装”操作都会导致数据丢失
最常被跳过的动作是验证 purge 是否真生效：执行 PURGE BINARY LOGS BEFORE '2026-03-25 00:00:00'; 后，必须跟一句 ls -lh /var/lib/mysql/mysql-bin.* | tail -5 确认文件数和大小确实减少，而不是只信 SHOW BINARY LOGS; 返回的列表。
