不能直接解析备份文件算增长，因其不含结构化度量；应定期采集information_schema.TABLES数据并存入历史表，结合innodb_file_per_table状态与data_free波动性区分逻辑与物理占用。
information_schema.TABLES 不记录历史，备份文件本身也不带“增长”元数据——想靠备份文件反推表空间增长趋势，本质是用错数据源。真正可行的方式，是把备份当作采样快照点，从中提取物理文件大小做横向对比。
为什么不能直接解析备份文件来算增长？
mysqldump 输出的是 SQL 文本，xtrabackup 备份的是 ibd + redo 日志的二进制拷贝，二者都不包含「某张表在某天占多少 MB」的结构化度量。你解压一个 .sql.gz 或挂载一个 xtrabackup 备份，仍需重新导入或扫描才能拿到 data_length + index_length，成本高、不可靠、无法自动化。
真正能落地的增长趋势统计：靠定期采集 information_schema.TABLES
必须主动建表存历史快照，否则所有“趋势”都是拍脑袋。推荐做法：
- 建专用库
db_monitor和表table_size_history，字段至少含：db_name、table_name、total_size_bytes、record_time - 用存储过程封装采集逻辑，例如：
CALL db_monitor.record_table_sizes('prod_db'); - 通过
crontab每日凌晨 2 点定时执行，确保时间点稳定、无业务干扰 - 查日增/月增时，用窗口函数或自连接比对相邻记录，例如：
LAG(total_size_bytes) OVER (PARTITION BY db_name, table_name ORDER BY record_time)
如果只有备份文件，怎么抢救式估算？
当没做历史采集，但手头有多个时间点的 xtrabackup 全备目录（如 backup_20260501/、backup_20260601/），可走文件系统路径硬统计：
- 确认备份中是否启用了
innodb_file_per_table=ON（查备份内my.cnf或SHOW VARIABLES LIKE 'innodb_file_per_table';） - 进入每个备份的数据库子目录，运行：
find ./prod_db -name "*.ibd" -exec du -b {} + | awk '{sum += $1} END {print sum}' - 注意排除
ibdata1（若innodb_file_per_table=OFF，所有表共用它，无法分表统计） - 结果只是近似值：因为
.ibd文件大小含未回收的data_free，且不包括 binlog、undo、tmpdir 临时文件等真实磁盘压力来源
容易被忽略的关键点
增长趋势失真的最大陷阱，不是 SQL 写错，而是忽略了 innodb_file_per_table 的开关状态和 data_free 的波动性。一张表 data_length + index_length 显示 100MB，实际 .ibd 文件可能已达 180MB —— 这多出来的 80MB 是 B+ 树分裂后未收缩的空间，下次 OPTIMIZE TABLE 可能直接释放掉。不区分「逻辑占用」和「物理占用」，所有增长率数字都只是幻觉。
