MySQL获取表磁盘空间大小的唯一可靠方式是查询information_schema.TABLES，通过DATA_LENGTH和INDEX_LENGTH字段计算总大小并转为MB，按降序排列；该值为InnoDB估算值，非实时精确字节，但日常分析足够可靠。
查 information_schema.TABLES 是唯一可靠方式
MySQL 没有内置命令直接列出所有表的磁盘占用，必须查系统库 information_schema.TABLES。它记录了每张表的 DATA_LENGTH（数据大小）、INDEX_LENGTH（索引大小）和 TABLE_ROWS 等元信息。注意：这些值是 InnoDB 的估算值，不是实时精确字节数，但对日常分析足够可靠。
关键字段含义：
-
DATA_LENGTH：表数据部分占用的字节数（不含索引） -
INDEX_LENGTH：该表所有索引占用的字节数 -
DATA_FREE：InnoDB 中未使用的空间（常为 0 或大数，意义有限，一般忽略） -
ENGINE：确认是否为 InnoDB/MyISAM，因为 MyISAM 的DATA_LENGTH更接近真实值
执行带单位换算和排序的查询语句
直接查原始字节不直观，需转换为 KB/MB 并按总大小倒序排列。以下语句适用于当前数据库（替换 YOUR_DATABASE_NAME）：
SELECT TABLE_NAME AS `table`, ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2) AS `size_mb`, ROUND(DATA_LENGTH / 1024 / 1024, 2) AS `data_mb`, ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS `index_mb`, TABLE_ROWS AS `rows` FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'YOUR_DATABASE_NAME' ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;
常见疏漏点：
- 忘记加
WHERE TABLE_SCHEMA = ...，否则会查出所有数据库的表，结果冗长且权限可能不足 - 用
SUM()聚合时没加GROUP BY，导致只返回一行错误汇总 - 误把
AVG_ROW_LENGTH当实际大小——它只是平均行长估算，不能用于计算总空间
区分 InnoDB 表空间类型的影响
InnoDB 有两种表空间管理方式：innodb_file_per_table=ON（默认）和 OFF。这直接影响你看到的大小是否“可落地”：
- 当
ON时，每张表对应一个.ibd文件，DATA_LENGTH + INDEX_LENGTH值与文件大小基本一致（误差在页对齐范围内） - 当
OFF时，所有表共享ibdata1，此时DATA_LENGTH仅是逻辑估算，.ibd文件不存在，无法通过文件系统验证 - 可通过
SHOW VARIABLES LIKE 'innodb_file_per_table';查看当前设置
为什么 SHOW TABLE STATUS 不推荐用于空间统计
SHOW TABLE STATUS 也能显示 Data_length 和 Index_length，但它有硬伤：
- 不能用
WHERE过滤数据库名，必须先USE db_name，不适合脚本批量执行 - 输出是混合格式（含字符集、引擎等冗余字段），难解析；而
information_schema.TABLES是标准表结构，可直接 JOIN 或导出 - 某些 MySQL 版本中，
SHOW TABLE STATUS在高并发下可能卡住或返回过期缓存值 - 它不支持
ORDER BY和聚合函数，想看“最大的前 5 张表”必须靠客户端处理
真正需要精确到字节级的场景（比如清理归档前校验），得登录服务器用 ls -lh /var/lib/mysql/YOUR_DATABASE_NAME/*.ibd 对照查看——但那是运维操作，不在 SQL 范畴内了。
