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