8

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

我使用它是因为我想显式地命名结果集中的列。但是,使用替代查询对此进行编码会添加一行额外的代码,该代码行在<2 mSec中运行:

SHOW TABLES LIKE '<TablePrefix>%';

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

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

4

2 回答 2

9

对于那些可能想要一个小缺点的黑客: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;
于 2013-05-09T18:58:29.043 回答
4

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

看看这篇文章 -优化 INFORMATION_SCHEMA 查询;在某些情况下,它会帮助你。

于 2012-07-02T12:26:37.723 回答