Question

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

我想在之前和之后做一个大小的基准测试，并且它们都是（据我所知）innoDB表。

所以，我通过此链接使用information_schema表：https://www.percona.com/blog/2008/03/17/researching-your-mysql-table-sizes/ 这很好，除了列出的第一个查询（我猜其他的）只是运行并运行并最终在 EIGHT MINUTES 之后完成。

我可以立即运行此查询：

SELECT COUNT(*) FROM information_schema.TABLES;

获得约12,500张桌子。

我还注意到 - 具有讽刺意味的是 - 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没有“真实”表格，因此无法添加INDEXes。

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

60是一个数量可观的数据库; 12K是大量的表。这通常意味着架构设计选择创建多个表而不是将数据放入单个表中吗？