删除连接池中的“清除”MySQL连接安全吗？

Question

请考虑以下连接列表：

+----------+---------+------+------------------------+
| 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和AWS工程师处理的，他们告诉我们，如果应用程序不能正确地关闭连接，标准的"wait_timeout“将无法工作。在Aurora中，"wait_timeout“已成为无用的装饰，但让我们在其他线程/主题中使用它。

因此，无论如何，我们有这个神奇的可配置参数从第三方供应商设置在这个晦涩的应用程序，控制驱逐陈腐的连接和它的工作。

问题：

立即排除处于“清理”状态的连接安全吗？

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

我不知道连接池的内部内脏是如何从数据库中看到的。默认情况下，连接池的所有保留连接都处于“清除”状态中“休眠”吗？

所以说，如果你开始清理太多，你会积极战斗连接池，创造更多的补充？

还是保留的连接有不同的状态？

，即使您不完全理解上下文，我也希望经验丰富的DBA或连接池库维护人员在这些问题上提供帮助。否则会弄脏我的手，最终自己回答这个问题，会尝试apache连接池，hikari，观察它们并尝试关闭它们的空闲连接(模拟魔术参数)，并尝试使用这个带有0秒魔术参数的第三方应用程序连接，看看它是否仍然有效。

感谢你的时间:鞠躬：.

Answer 1

答案

是的，来自AWS论坛(https://forums.aws.amazon.com/thread.jspa?messageID=708499)

中的Aurora‘清理’状态是一个连接的最后状态，它的工作已经完成，但还没有从客户端关闭。在MySQL中，此字段在相同的情况下保留为空白(无状态)。

也来自同一职位：

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

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