information_schema.tables 查询慢答案

【问题标题】：Slow query on information_schema.tablesinformation_schema.tables 查询慢
【发布时间】：2012-07-02 16:13:36
【问题描述】：

我在一个典型的共享托管服务产品上运行一组自行开发的应用程序。我从允许表的静态配置表列表移动到基于 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>%';

我使用它是因为我想明确命名结果集中的列。但是，使用替代查询围绕此进行编码会添加一行额外的代码，该代码行在 中运行：

SHOW TABLES LIKE '<TablePrefix>%';

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

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

【问题讨论】：

【解决方案1】：

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

看看这篇文章 - Optimizing INFORMATION_SCHEMA Queries;在某些情况下，它会对您有所帮助。

【讨论】：

Devant，谢谢。我对表名上的 'prefix_%' like 子句使用了常量数据库名称和常量模式，因此查询接近最佳状态。但是，我还查看了本节的 5.0 和 5.1 版本。 5.1 版本澄清了这些性能优化仅在 5.1.21 中引入，因此我认为不适用于 5.0.92。因此，MySQL 引擎充其量是在进行数据库目录扫描以返回此信息。此表中的“ENGINE=MEMORY”子句具有误导性。我仍然想不通的是为什么节目版本如此之快。
我为 SHOW TABLES LIKE 语句做了一个 mysqld 的 strace，这做了一个 DB 目录的 openat()，获取目录条目，然后打开与模式匹配的表的每个 FRM 文件，但这些都在我系统的 VFAT 缓存中，所以这需要几毫秒。 SELECT 语句的事件速度更快，因为它执行相同的 openat()+getents() 但不打开 FRM 文件。所以我想这是我的托管服务提供商仍在使用 MySQL 5.0 的一个功能
您的回答将我推向了正确的方向，并帮助我自己回答了问题。很遗憾，我已经废弃了我的旧 Ubuntu 8.04 VM，所以我没有可以 strace 运行 MySQL 5.0 的 LAMP 堆栈，但我很高兴 I_S 查询的未优化方面和完整扫描是根本问题.

【解决方案2】：

它的作用是禁用一些在您查询架构时会更新的统计信息，更多信息在这里：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;

【讨论】：

感谢这个反馈，但这是一个 MySQL over MyISAM 问题，我最终追踪了 5.0 和 5,1 的 MYSQL 守护程序以了解它的底部。您的修复对 OQ 没有帮助。
注意 innodb_stats_on_metadata 设置在 MySQL 5.0 中不可用