mysql - 使用 information_schema 查找 innodb 数据库的大小

Question

我们的 RDS 服务器上大约有 60-70 个数据库，其中很多都可以删除。

我想做一个前后大小的基准，它们都是(据我所知)innoDB表。

因此，我通过此链接使用 information_schema 表:https://www.percona.com/blog/2008/03/17/researching-your-mysql-table-sizes/这很棒，除了列出的第一个查询(我认为其他查询)只是运行并运行并最终在八分钟后完成。

我可以立即运行此查询:

SELECT COUNT(*) FROM information_schema.TABLES;

大约有 12,500 张 table 。

我还注意到 - 具有讽刺意味的是 - information_schema.TABLES 没有索引!我的本能是不要搞乱它。

此时我最好的选择是转储 TABLES 表，并在我实际索引的副本上运行查询。

我的问题是:1. information_schema.TABLES 表以及整个数据库的动态程度如何2.为什么运行这么慢？3.是否建议对一些关键字段建立索引来优化我想做的查询？4. 如果我执行 SQL 转储，我会获得当前表大小信息吗？

谢谢，我希望这个问题具有启发性。

Answer 1

information_schema 目前是一些旧内容之上的薄层。较旧的东西需要“打开”每个表以发现其大小等。这至少涉及读取 .frm。但不需要打开它来计算表的数量。想想 SHOW TABLES 和 SHOW TABLE STATUS 之间的区别。

当您进行 8 分钟查询时，

table_open_cache 和 table_definition_cache 可能确实包含了其中的所有表。无论如何，这些 VARIABLES 的值可能小于 12,500，这意味着可能会出现流失。

在未来(可能是 5.8)，所有这些信息可能将位于单个 InnoDB 表中，而不是分布在操作系统的文件系统中。到那时，速度会相当快。 (想想 12,500 行的表扫描可以多快完成，特别是如果完全缓存在 RAM 中的话。)

由于 information_schema 没有“真实”表，因此无法添加 INDEX。

mysqldump 不提供表大小信息。即使这样做，也不会更快，因为它会经历相同的旧机制。

60 个数据库的数量令人怀疑； 12K是一个很大的表数。通常这意味着架构设计选择创建多个表而不是将数据放入单个表中？