MySQL磁盘使用率分析需聚焦表数据（.ibd）、系统表空间（ibdata1）、日志文件等，用SQL按库汇总大小、查大表及碎片率，并检查binlog、错误日志等非表文件，结合OS命令定期监控。
MySQL 的磁盘使用率分析，核心是定位哪些文件或数据占用了大量空间，而不是只看整个数据库目录大小。关键要区分：表数据（.ibd）、系统表空间（ibdata1）、日志文件（ib_logfile*、binlog）、临时文件和慢查日志等。
查看各数据库实际占用的磁盘空间
执行以下 SQL 可按数据库汇总数据和索引大小（单位 MB），结果较准确（基于 InnoDB 表的 information_schema.tables）：
注意：该统计不包含日志、临时文件等，但覆盖了绝大部分业务数据。
SELECT table_schema AS '数据库', ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS '大小(MB)' FROM information_schema.TABLES GROUP BY table_schema ORDER BY SUM(data_length + index_length) DESC;
定位大表和碎片率高的表
单个表膨胀或存在高碎片，会显著推高磁盘占用。运行以下语句找出前 10 个最大且碎片率 > 10% 的表：
SELECT
table_schema,
table_name,
ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb,
ROUND(data_free / 1024 / 1024, 2) AS free_mb,
ROUND(100 * data_free / (data_length + index_length + 1), 2) AS frag_pct
FROM information_schema.TABLES
WHERE engine = 'InnoDB'
AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
AND data_length > 0
HAVING frag_pct > 10
ORDER BY size_mb DESC
LIMIT 10;说明：
- data_free 是 InnoDB 为该表预分配但未使用的空间（来自表空间）；
- 若 frag_pct 高，说明 OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB 可能释放空间（需评估锁和复制延迟）；
- 对于大表，建议在低峰期操作，并确认 binlog_format 兼容性（ROW 模式更安全）。
检查非表数据类文件的实际占用
登录 MySQL 服务器操作系统，用命令快速识别“隐形大户”：
-
二进制日志（binlog）：执行
SHOW BINARY LOGS;查看当前 binlog 列表，再用ls -lh /var/lib/mysql/mysql-bin.*（路径以datadir和log_bin_basename配置为准）看体积；清理前确认从库已同步，并用PURGE BINARY LOGS安全删除。 -
错误日志、慢查询日志：检查
slow_query_log_file和log_error配置项指向的路径，大日志文件可能因未轮转而持续增长。 -
临时文件和 undo 日志：若
innodb_temp_data_file_path或innodb_undo_directory指向独立磁盘，也需单独监控；长时间运行的大事务可能导致 undo 表空间膨胀。
定期监控与自动化建议
避免临时救火，推荐建立基础监控习惯：
- 每天定时用
du -sh /var/lib/mysql/* | sort -hr | head -20快速扫描目录级变化； - 将前述 SQL 封装为脚本，配合
mysql -N -s输出纯文本，写入日志并对比趋势； - 对业务增长快的表，提前规划归档策略（如按时间分区 +
DROP PARTITION）； - 启用
innodb_file_per_table=ON（默认开启），确保每个表可独立收缩，避免共享表空间无限膨胀。
