我一直在研究有关数据库池的整个网络，但是我仍然不了解我希望从更有经验的开发人员那里找到答案的几件事。
我对数据库池的理解是，当有多个客户端连接到数据库时，将连接保持在“缓存”中并使用该连接更快地连接到数据库是有意义的。 我无法理解的是，如果我有一个连接到数据库并保持连接打开的服务器，那将有什么帮助。当客户端从端点请求数据时，服务器将使用相同的连接来检索数据。在这种情况下，池化将如何提供帮助？
我确定我对池的理解有所遗漏。如果存在同一个数据库的多个实例，这将是有道理的，因此可以使用缓存的凭据在池中确定要连接到哪个数据库。那里发生什么了吗？
您还能给我一个应该使用数据库池的场景吗？
感谢您澄清我的任何疑问。
答案 0 :(得分：1)
在.Net中，连接池是自动处理的，而不是由您的应用程序直接处理的。
您需要做的只是正常地打开，使用和关闭连接，其余的都将由您处理。
https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql-server-connection-pooling
如果您要谈论的是不同的平台，则机制是不同的，尽管目的是相同的。
在所有情况下，打开和关闭与DB服务器的连接都是很耗时的，因此，应用程序和DB服务器之间的某些内容（通常是数据库驱动程序或某种中间件）将维护一个开放连接池，并且根据需要创建，杀死和回收它们。
池使连接保持打开状态，并减少了为每个请求打开一个连接的开销。
您还能给我一个应该使用数据库池的场景吗？
连接池在连接池的生存期内多次使用同一数据库连接的任何应用程序中很有用。
如果您的应用程序只使用过一次连接，然后在连接池中再没有使用过，那么实际上它们的性能实际上会非常非常稍微降低已超时并回收。这在生产应用程序中非常罕见。
我无法理解的是，如果我有一个连接到数据库并保持连接打开的服务器，那将有什么帮助。
如果您有一个打开连接并保持打开状态的应用程序，那么从理论上讲池化将无济于事。实际上，最好定期杀死并重新创建各种资源，例如连接，句柄，套接字等，因为软件不是完美的，并且某些代码包含资源泄漏。
我只是在猜测，但是怀疑您担心的是premature optimization。除非您进行了实际测试并确定连接池是个问题，否则我不会太在意。连接池通常是自我维护的，几乎总是可以提高性能。
答案 1 :(得分：1)
在不同的应用程序场景和平台/语言中，连接池的处理方式有所不同。
主要考虑因素是数据库连接是一种有限的资源，建立它花费时间。
连接是有限的，因为大多数数据库服务器都对并发连接数施加了最大限制（这可能是许可条款的一部分）。如果您的应用程序使用的连接数超出数据库允许的数量，则它可能会开始拒绝连接（导致客户端应用程序中出现错误处理要求），或者使连接等待（导致响应时间变短）。通过配置连接池，客户端应用程序可以在中央位置管理这些方案。
第二，管理连接有点麻烦-存在许多不同的错误处理方案，配置设置等；集中化这是一个好主意。您当然可以在没有连接池的情况下做到这一点。
第三，连接是“昂贵”的资源-建立连接需要花费时间。大多数网页需要几个数据库查询。如果每个查询只花十分之一秒的时间来建立数据库连接，那么您很快就会花费大量时间等待数据库连接。通过使用连接池，可以避免这种开销。