MySQL 库表容量统计

这条语句的思路很直接：

• AVG_ROW_LENGTH * TABLE_ROWS：估算数据区大小
• INDEX_LENGTH：索引占用大小
• 最后统一换算成 MB，方便阅读

不过前面也提到过，这里用到的行数是估算值，所以结果更适合做容量观察和趋势判断，不适合作为严格审计口径。

三、按库查看容量

如果你想进一步定位是哪个库占得多，可以按 TABLE_SCHEMA 分组统计：

SELECT
    TABLE_SCHEMA AS db_name,
    CONCAT(ROUND(SUM(DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2), 'MB') AS total_size
FROM information_schema.TABLES
GROUP BY TABLE_SCHEMA
ORDER BY SUM(DATA_LENGTH + INDEX_LENGTH) DESC;

这样可以很快看出哪个库最'重'。在实际排查磁盘占用、容量异常增长时，这一步通常特别有用。

四、按表查看容量

如果要继续往下挖，看看某个库里到底是哪几张表最占空间，也可以直接按表统计：

SELECT
    TABLE_SCHEMA,
    TABLE_NAME,
    CONCAT(ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024, 2), 'MB') AS total_size,
    CONCAT(ROUND(DATA_LENGTH / 1024 / 1024, 2), 'MB') AS data_size,
    CONCAT(ROUND(INDEX_LENGTH / 1024 / 1024, 2), 'MB') AS index_size
FROM information_schema.TABLES
ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC;

这类结果通常一眼就能看出：

• 哪些表是容量大户
• 是数据本身大，还是索引膨胀得厉害
• 是否存在某些表明显异常增长

五、补充说明

information_schema 提供的是元数据层面的统计，它的价值在于快、方便、无需扫描整表。对于日常运维和容量评估来说，这已经足够好用。

但如果你需要非常精确的物理占用分析，尤其是面对 InnoDB 表时，还要结合表空间文件、压缩策略、碎片情况等因素一起看。换句话说，information_schema 更适合做'先摸个底'，而不是替代完整的容量审计。

小结

MySQL 里统计库表容量并不复杂，核心还是围绕 information_schema.TABLES 里的几个字段展开。想看整体大小，就汇总 DATA_LENGTH；想看总占用，就把数据和索引一起算进去；想定位问题，就按库、按表继续拆分。对于容量治理、空间回收、慢慢膨胀的大表排查，这几条 SQL 往往就是最先派上用场的工具。