是"；“清理干净”；连接池中的MySQL连接是否可以安全删除？

考虑以下连接列表：

+----------+---------+------+------------------------+
| ID       | COMMAND | TIME | STATE                  |
+----------+---------+------+------------------------+
| 87997796 | Sleep   |   15 | cleaned up             |
| 90850182 | Sleep   |  105 | cleaned up             |
| 88009697 | Sleep   |   38 | delayed commit ok done |
| 88000267 | Sleep   |    6 | delayed commit ok done |
| 88009819 | Sleep   |   38 | delayed commit ok done |
| 90634882 | Sleep   |   21 | cleaned up             |
| 90634878 | Sleep   |   21 | cleaned up             |
| 90634884 | Sleep   |   21 | cleaned up             |
| 90634875 | Sleep   |   21 | cleaned up             |
+----------+---------+------+------------------------+

在一分钟内经过一段短时间后：

+----------+---------+------+------------------------+
| ID       | COMMAND | TIME | STATE                  |
+----------+---------+------+------------------------+
| 87997796 | Sleep   |    9 | cleaned up             |
| 88009697 | Sleep   |   32 | delayed commit ok done |
| 88000267 | Sleep   |    9 | delayed commit ok done |
| 88009819 | Sleep   |   31 | delayed commit ok done |
| 90634882 | Sleep   |   14 | cleaned up             |
| 90634878 | Sleep   |   14 | cleaned up             |
| 90634884 | Sleep   |   14 | cleaned up             |
| 90634875 | Sleep   |   14 | cleaned up             |
+----------+---------+------+------------------------+
8 rows in set (0.02 sec)
enter code here

在我写完这篇文章之后：

+----------+---------+------+------------------------+
| ID       | COMMAND | TIME | STATE                  |
+----------+---------+------+------------------------+
| 87997796 | Sleep   |    0 | cleaned up             |
| 88009697 | Sleep   |   53 | delayed commit ok done |
| 88000267 | Sleep   |    0 | delayed commit ok done |
| 88009819 | Sleep   |   52 | delayed commit ok done |
| 90634882 | Sleep   |    5 | cleaned up             |
| 90634878 | Sleep   |    5 | cleaned up             |
| 90634884 | Sleep   |    5 | cleaned up             |
| 90634875 | Sleep   |    5 | cleaned up             |
+----------+---------+------+------------------------+

上下文：

这是一些第三供应商应用程序打开连接（源代码对我们不可用，所以我们不知道详细信息）。我们知道他们的连接管理很糟糕，他们也知道这一点。这很糟糕，因为您可以在第一个表中看到连接泄漏-90850182。如果其他人重置了他们的计时器，那么这个计时器开始无限期地老化。在旧版本的应用程序中，它将永远存在。在较新的版本中，它最终被供应商引入的“补丁”捕获，该补丁在您指定的x秒后有效地清理连接。所以这是一个“漏洞修复补丁”

问题：

我们托管了数百个这样的供应商应用程序，其中大多数都有超过8个连接，因为它们的流量更大。这就导致了我们不得不维持的令人厌恶的联系数量（数千）。大约80%的连接处于“已清理”状态，不到120秒（最终通过前面提到的可配置应用程序参数清理）

这一切都由Aurora RDS处理，AWS工程师告诉我们，如果应用程序不能正确关闭连接，标准的“等待超时”将无法工作。“等待超时”在AWS Aurora中变成了无用的装饰，但让我们在其他线程/主题中与Jeff一起讨论

所以不管怎样，我们在这个晦涩难懂的应用程序上设置了来自第三方供应商的这个神奇的可配置参数，它可以控制陈旧连接的清除，并且可以正常工作

问题：

立即清除处于“已清理”状态的连接是否安全

目前，这种情况发生在120秒后，导致大量此类连接。然而，在上面的表格中，您可以看到计时器被重置，这意味着这些连接正在发生某些事情，并且它们并非完全过时。例如，应用程序的连接池“接触”它们以供进一步重复使用

我不知道连接池的内部结构，也不知道它们是如何从数据库中看到的。默认情况下，连接池的所有保留连接都处于“已清理”状态吗

所以说，若你们开始清理太多，你们会积极地对抗连接池，创造更多的补充

或者保留连接有不同的状态

即使您不完全了解上下文，我也希望经验丰富的DBA或连接池库维护人员能够帮助您解决这些问题。否则，我会弄脏我的手，最终自己回答这个问题。我会尝试apache连接池、hikari，观察它们并尝试杀死它们的空闲连接（模拟magic参数），然后使用0秒magic参数尝试这个第三方应用程序连接，看看它是否仍然有效。

感谢你的时间：鞠躬：。

答案

是的，来自AWS论坛（）

在极光中，“清理”状态是连接的最终状态 其工作已完成，但尚未从客户端关闭 一边在MySQL中，此字段在相同的字段中保留为空（无状态） 环境

同样来自同一职位：

最终，在代码中显式关闭连接是最好的 这里的解决方案

---

根据我作为MySQL DBA的个人经验，并且知道“清理”代表一个空白状态，我肯定会终止这些连接。

这更像是DBA问题/服务器问题。当你的网站被godd编程时，只要你的网站没有关闭，或者超过mysql连接等待时间，连接只会被打开。如果连接池被高估，连接池将回收它们。是否有限制连接数量的配置？将其调低到0或1。我无法限制连接数，因为第三方应用程序将停止工作并返回500个被拒绝的连接。