在 MySQL (Azure) 上查询 Information_Schema 耗时过长答案

【问题标题】：Querying Information_Schema on MySQL (Azure) takes too long在 MySQL (Azure) 上查询 Information_Schema 耗时过长
【发布时间】：2019-12-19 02:46:48
【问题描述】：

问题是从 MySql 读取信息架构...太慢了：

步骤：

1. MySql dump created manually by scripting all objects from existing
   MySql db which is on AWS. (MySql Version 5.7)
2. Restored dump file on to Azure MySql (Version 5.7)
3. Re-pointed Application (Appian) which sits on AWS to newly created MySql db on Azure.
4. When tried to validate Application (Appian) Objects (Data Stores), which reads `Information_Schema` takes too long or gets timed out.
5. But reading data from the tables are faster.

根据检查的建议 innodb_stats_on_metadata，此设置为 OFF。

仍然没有运气！有什么建议吗？

经过一番调查，发现下面的查询是慢的。

SHOW FULL TABLES FROM `database` LIKE 'xyz'

大多数时候它的作用是'checking permissions'

【问题讨论】：

您是否分析了表 tbl_name；对于在 Azure MySQL 5.7 上还原的每个表？在 ANALYZE 之后，所有索引都将是最新的。
来自 Azure MySQL 的附加信息请求。 RAM 大小、# 内核、MySQL 主机服务器上的任何 SSD/NVME 设备？在 pastebin.com 上发布并分享链接。从 SSH 登录根，文本结果： B) SHOW GLOBAL STATUS; C) 显示全局变量； D) 显示完整的处理程序； F) 显示 ENGINE INNODB 状态； G) SELECT name, count FROM information_schema.innodb_metrics ORDER BY name;为服务器工作负载调优分析提供建议。
@Wilson：将很快更新所需的详细信息。我发现大部分时间都被我的查询 SHOW FULL TABLE FROM LIKE 用于执行它正在检查权限，这很慢。

标签： mysql amazon-web-services information-schema azure-mysql-database appian

【解决方案1】：

来自微软的回应：

经产品工程确认后，Azure MySQL 5.7 上的命令 show full tables 比预期慢。每次测试，1500张表只有1个连接线程需要800ms才能完成，当存储更多的表和并行连接时，响应时间会相应增加。

关于这个问题，我们现在可以尝试两种可能的方法：

继续使用 MySQL 5.7，下一个版本（2020 年 1 月末）将通过将 1500 个表和 1 个线程的响应时间减少到 50 毫秒来缓解此问题。
切换到 MySQL 8.0 版本，因为 8.0 在运行show full tables 时没有“列出所有目录”之类的操作。目前 8.0 处于发布预览阶段，暂定 GA 也是 2020 年 1 月下旬。

【讨论】：