共计 725 个字符，预计需要花费 2 分钟才能阅读完成。
作者：李鹏博
爱可生 DBA 团队成员，次要负责 MySQL 故障解决和 SQL 审核优化。对技术执着，为客户负责。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
—
最近发现客户的一台 MySQL 5.7.32 实例的监控线程状态始终处于 Opening table 状态，且都是在对 information_schema.tables 表做相干查问，如图：
通过 show open tables ; 语句发现 opened tables 并不算太多：
相干参数也没有太大的不合理性：
尽管 ulimit 设置不是很大，然而也不会对此产生什么影响
查看 MySQL Error 日志也没有发现与此相关的异样。
因而只能应用 pstack 工具对 MySQL 打堆栈来进行剖析，堆栈日志如下：
通过剖析堆栈日志发现，问题呈现在进行查问时会应用 Federated 存储引擎表对近程实例进行查问。
查看数据库应用 Federated 存储引擎的表，发现有两张表应用了 Federated 存储引擎：
通过在实例服务器上 Telnet Feferated 服务端的实例 IP 和端口发现是不通的：
所以揣测问题起因为：监控线程在查问 information_schema.tables 表时，当须要获取 Federated 存储引擎表的信息时须要连贯远端 Server，而因为网络或其余起因无奈连贯时，就会导致本地监控线程处于 Opening table 状态。
接下来设计试验验证咱们的想法：
- 启用 Federated 存储引擎
- 创立一张 Federated 存储引擎的表，连贯的 server 不存在
- 查问 information_schema.tables 表，线程卡住
- 线程状态处于 Opening table 状态
这刚好验证了咱们的想法是正确的。
正文完
