考虑下面的连接列表。
+----------+---------+------+------------------------+
| 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
在我写完这个stackoverflow的帖子后，
+----------+---------+------+------------------------+
| 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 |
+----------+---------+------+------------------------+
上下文:
这是一些第3供应商的应用程序打开连接（源代码没有提供给我们，所以我们不知道细节）。我们知道他们的连接管理很糟糕，他们也知道。它是可怕的，因为连接泄漏，你可以看到在第一个表 - 。90850182. 如果其他人的计时器被重置，那么这个开始无限老化。在旧版本的应用中，它会永远停留。在新版本中，它最终会被厂商推出的一个 "补丁 "所捕获，它能有效地在你指定的x秒后清理连接。所以这就是 "治漏补丁"。
问题是:
我们正在托管数百个这样的供应商应用程序，其中大多数有超过8个连接，因为他们有更多的流量。这就导致了我们不得不维护的令人厌恶的连接数(成千上万)。大约80%的连接处于 "清理 "状态，并且在120秒以内（最终由上述可配置的应用参数清理）。
这一切都由Aurora RDS处理，AWS工程师告诉我们，如果应用程序不能正确关闭连接，标准的 "wait_timeout "是不会工作的。好吧，"wait_timeout "在AWS Aurora中成了无用的装饰，但让我们在其他线程topic中和Jeff一起讨论。
所以无论如何，我们在这个不知名的应用上设置了这个来自第三方厂商的神奇的可配置参数，它可以控制驱逐陈旧的连接，并且它可以工作。
问题是
立即驱逐处于 "清理 "状态的连接是否安全？
目前，这种情况发生在120秒后，这将导致大量的此类连接。然而在上面的表格中，你可以看到计时器被重置，这意味着这些连接正在发生一些事情，而且它们并不是完全失效的。即应用程序的连接池 "触动 "了它们以进一步重复使用？
我不知道连接池的内幕，因为他们是如何从数据库中看到的。连接池中所有保留的连接是否默认为 "清理 "状态下的 "睡眠"？
所以说如果你开始清理的太多，你会积极的打击连接池创造更多的连接来补充？
或者说保留的连接有一些不同的状态？
即使你不完全理解上下文，我也希望资深的DBA或者连接池库维护者能够帮助解决这样的问题。否则最终会自己动手回答这个问题，会尝试apache连接池，hikari，观察他们，并尝试杀死他们的空闲连接（模拟魔力参数），并尝试这个第三方app连接的0秒魔力参数，看看是否还能用。
感谢你的时间：鞠躬：。