我们最近将 MySQL 数据库从 5.7 升级到 8.0，并将所有排序规则从 latin 更改为 utf8 mb4。
大多数情况下，这非常顺利，它解决了我们试图解决的问题。但它产生了另一个我们不理解的问题。
我们在数据库中有一个很长的查询，需要 65 次连接（别问，我知道这很糟糕，我们正在对其进行设计，但我们现在坚持下去）。
我们让它在 5.7 上工作的方式是创建一个包含 60 个连接的查询，然后创建另一个包含 5 个连接的查询，然后将每个连接的结果连接在一起。
自升级以来，第一个查询（有 60 个连接）不再运行。相反，我们得到“错误代码 2013：在查询期间失去与 MySQL 服务器的连接”。此错误在运行查询后立即（0.2 秒）发生。其他查询似乎运行良好。
我们已经尝试了针对此错误推荐的常用方法
- 增加连接超时
- 增加最大允许数据包大小
- 增加网络读取超时
- 增加 innodb 缓冲池大小
- 运行mysql升级
但没有运气。
我们确实有一个解决方法是减少连接的数量。因此，我没有 60 个连接和 5 个连接，而是有 40 个连接和 25 个连接。在这种情况下，我可以使两个查询都运行良好。有趣的是，连接的 50/15 拆分仍然不起作用。
但是解决方法并不能帮助我理解出了什么问题，因为 60 连接查询应该仍然有效，即使它是一个丑陋的查询。所以我对在我们的实时服务器上进行升级感到紧张，除非我可以确定这个问题并不表示存在更大的问题。
问题查询在这里 https://www.codepile.net/pile/nN4XG6N4
编辑我刚刚注意到其他有趣的事情。在我们升级到 MySQL8.0 的服务器上，我们的配置略有不同
table_open_cache = 2000
open_files_limit = 1048576
但是在 MySQL5.7 服务器上（查询运行没有错误）的配置是
table_open_cache = 3495
open_files_limit = 10000
由于运行时错误日志中的一些警告，我选择了这个
2021-12-09T12:35:11.722898Z 0 [警告] [MY-010140] [服务器] 无法将 max_open_files 的数量增加到超过 10000 (r$ 2021-12-09T12:35:11.722915Z 0 [警告] [ MY-010142] [服务器] 更改限制：table_open_cache：3495（请求 4000）
这是否有助于提供更多信息？
另一个编辑
不是这样，我们增加了这些设置以匹配。我们停止收到警告，但它并没有解决问题。