表大小与磁盘文件大小不一致的根本原因是information_schema.TABLES仅统计逻辑数据量，而物理占用受文件系统块对齐、引擎结构、共享表空间及未回收碎片等影响。
查出来的表大小和磁盘上看到的文件大小对不上
这是最常被问到的问题，根本原因在于 information_schema.TABLES 里的 data_length 和 index_length 只反映逻辑数据量，不等于物理磁盘占用。比如你删掉 90% 的数据，data_length 会变小，但 .ibd 文件通常不会自动收缩（除非执行 OPTIMIZE TABLE 或 ALTER TABLE ... ENGINE=InnoDB）。更关键的是：
- 若
innodb_file_per_table=OFF，所有表都挤在共享表空间ibdata1里，而该文件大小完全不会出现在任何单表统计中 -
binlog、ib_logfile*、临时排序文件等都不计入表空间，但真实占磁盘 - 文件系统块对齐：一个 1KB 的记录可能实际占 4KB 磁盘空间，
du -sh看到的就是这个物理大小
MyISAM 和 InnoDB 的物理文件结构完全不同
这直接决定你该看哪个文件、怎么估算真实空间：
- MyISAM 表对应三个独立文件：
your_table.frm（结构）、your_table.MYD（数据）、your_table.MYI（索引）。du -sh your_table.*加起来基本就是它占的磁盘空间 - InnoDB 表默认（
innodb_file_per_table=ON）是每个表一个.ibd文件，du -sh your_table.ibd就是它的物理大小；但要注意.ibd文件内部有页管理开销（如空闲页、undo段预留），所以比data_length + index_length略大 - 如果
innodb_file_per_table=OFF，所有表都写进ibdata1，你无法从文件系统区分哪部分属于哪张表 —— 这时information_schema的统计就彻底失去物理参考价值
用 show variables like 'innodb_file_per_table' 判断是否能按表查物理文件
这条命令的结果决定了后续所有操作路径：
- 返回
ON：可以放心用ls -lh /var/lib/mysql/your_db/your_table.ibd查物理大小，也支持OPTIMIZE TABLE回收碎片空间 - 返回
OFF：必须立刻检查ibdata1大小 —— 它很可能已膨胀到几十 GB，而你的查询结果加起来才几 GB。迁移成本高，但长期来看建议导出重建库并开启该参数 - 注意：修改此参数只影响新建表，已有表仍留在原表空间，不会自动拆出
.ibd
data_free 字段不是“可用空间”，而是“已分配但未使用的页”
information_schema.TABLES.data_free 常被误读为“还能插入多少数据”，其实它表示该表分配了但尚未填满的数据页空间（单位字节）。它和物理文件大小的关系很间接：
- 对 InnoDB：
data_free是.ibd文件内未使用的页，但文件本身不会因此缩小；OPTIMIZE TABLE会重建.ibd并重置data_free接近 0 - 对 MyISAM：
data_free是.MYD中被删除记录留下的空洞，REPAIR TABLE或myisamchk -r才能真正回收 - 无论哪种引擎，
data_free > 0都不意味着磁盘空间可释放，除非你显式执行重建或修复操作
真正要确认一张表占了多少磁盘，得先看存储引擎，再看配置，最后落到具体文件 —— information_schema 提供的是逻辑快照，不是磁盘账本。尤其当 ibdata1 或 binlog 开始膨胀时，跳过这层验证，光看 SQL 结果很容易误判容量瓶颈。
