直接查information_schema.TABLES可获取各表磁盘占用，需将DATA_LENGTH与INDEX_LENGTH相加并除以1024²转为MB，按降序排列；该值为InnoDB估算值，非实时精确字节，但日常分析足够可靠。
直接查 information_schema.tables 就能拿到每个表的磁盘占用，但默认单位是字节，且 data_length 和 index_length 需要相加才是总大小——很多人只看其中一个，结果偏差很大。
查单个数据库里所有表的大小（含可读单位）
MySQL 自身不提供 KB/MB 自动换算，得自己用表达式处理。常用写法是把 data_length + index_length 除以 1024² 并保留两位小数：
SELECT table_name, ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb, table_rows FROM information_schema.tables WHERE table_schema = 'your_db_name' ORDER BY size_mb DESC;
注意：table_rows 是估算值（尤其 InnoDB），不能当作精确行数；size_mb 是磁盘上实际分配的空间，不是“有效数据”大小。
为什么 data_length 和 index_length 要加起来？
InnoDB 表的数据和索引都存放在同一个表空间（或独立表空间文件里），data_length 包含聚簇索引（主键）和二级索引的叶子节点数据，index_length 则包含非叶子节点、全文索引结构等额外开销。漏掉任一个，都会低估 20%–50% 的实际占用。
-
innodb_file_per_table = ON时，每个表对应一个.ibd文件，ls -lh查到的文件大小应与该查询结果基本一致 -
innodb_file_per_table = OFF时，所有表共享ibdata1，此时information_schema返回的是逻辑估算值，可能和磁盘文件不匹配
查整个实例所有表并按大小排序（慎用）
如果实例库很多，information_schema.tables 扫描会变慢，尤其在有上百个库、数千张表时。建议加 WHERE 过滤，避免无谓扫描：
SELECT
table_schema,
table_name,
ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY size_mb DESC
LIMIT 20;
不加 WHERE 直接查全部，可能触发元数据锁等待或拖慢其他查询；LIMIT 不是可选，是必须——否则返回几千行根本没法人工定位大表。
真正的大表识别，光看 MB 数不够，还得结合 table_rows 和平均行长判断是否存在大量碎片或历史数据未清理。比如一个 500MB 的表只有 1 万行，大概率是 BLOB 字段或索引膨胀，而不是数据量本身大。
