对information_schema.tables的查询速度慢

Question

我在典型的共享主机服务产品上运行一组自行开发的应用程序。我基于来自D / B元数据的前缀，基于表的列表，从允许的表的静态配置表列表移动到一个表。当我将此版本推广到公共服务时，我的每请求延迟平均增加 2.3-2.4秒。一些仪器显示这完全取决于一个SQL查询：

SELECT TABLE_NAME AS name
FROM information_schema.tables
WHERE TABLE_SCHEMA = '<DBname>'
AND TABLE_NAME LIKE '<TablePrefix>%';

我使用了这个，因为我想在结果集中明确命名列。但是，使用备用查询对此进行编码会添加一行额外的代码，这些代码在＆lt; 2 mSec 中运行：

SHOW TABLES LIKE '<TablePrefix>%';

我的服务提供商使用Enterprise MySql 5.0.92-50，因此我无法进行任何分析。这是一个扩展问题，因为它不会出现在我的开发环境和我可以分析的测试VM上。它们支持数千个用户，因此实时模式将非常大，但即便如此，连接和大多数查询只需要几毫秒。

有谁知道为什么在大型多用户系统上查询基于内存的information_schema需要这么长时间？

Answer 1

对于那些可能想要有一个小缺点的黑客的人：http://www.mysqlperformanceblog.com/2011/12/23/solving-information_schema-slowness/

它的作用是禁用一些在查询架构时会更新的统计信息，更多信息请参见：http://dev.mysql.com/doc/refman/5.1/en/innodb-parameters.html#sysvar_innodb_stats_on_metadata

为了让那些不想阅读的懒惰的流浪汉变得更容易，你只需要改变一个设置：

innodb_stats_on_metadata=0

您可以在配置文件中动态执行此操作：

mysql> set global innodb_stats_on_metadata=0;

Answer 2

信息模式没有优化，没有索引，只有带元数据的表，通常，当您从模式运行SELECT时，它会打开并读取文件。

看一下这篇文章 - Optimizing INFORMATION_SCHEMA Queries;在某些情况下，它会帮助你。