以下是我们可以在 Web 应用程序环境中用于数据库连接的不同技术。
Application Context Database Connection: 所有请求只共享一个数据库连接。 Database Pooling: 打开固定数量的数据库连接，并在所有请求之间共享连接。 New Database Connection per request:为每个请求打开一个连接。 这些技术的优缺点是什么？开发者应该使用哪一个？
【问题讨论】：
标签： mysql sql database postgresql database-connection
选项 1. 在所有 Web 用户之间共享单个数据库连接必然会由于某种原因而失败。一个长时间运行的查询和您的整个服务器将停止运行。对于 99.9% 的所有现代应用程序，甚至是非基于 Web 的应用程序，这是一个硬性的“不”。
选项 2. 连接池。可能是 Web 应用程序连接到数据库的第二常用技术。首先，如果 DB 和 Pool/Web 应用程序在同一台机器上，那么好处是非常有限的。但是，池和 Web 应用程序可以很容易地存在于同一硬件上。这里的好处是打开数据库连接的成本很高，并且在较小程度上保持打开的成本很高。打开连接需要 CPU 使用率和内存分配。池连接可以保持几十个连接几乎可以立即“附加”到。内存已经分配并且大部分设置工作已经完成，因此从池中连接和断开连接相对来说比较便宜。池通常始终保持一定数量的连接打开，并随着流量的增加而增长。在流量过大时，池通常会排队连接请求，以免数据库过载。队列后面的用户会遇到延迟，但系统会发生变化，并且通常不太可能由于内存不足而停止和磁盘交换。
选项 3. 每个请求的新数据库连接。在轻度到中度使用的系统上，这不是一个糟糕的选择，而且通常很容易在以后升级到 pooler。但是请记住，每个数据库连接（每个页面加载）都需要打开和关闭数据库连接，这涉及 CPU 和内存分配。在实践中，如果您的页面加载速度很快，您的用户群很小且一致，并且您的流量相当一致，那么它可以正常工作。许多 DEV、CAT 和 QA 环境直接连接，无需 pooler。缺点是#1，绝对没有办法控制与数据库的连接。如果查询挂起，您可能会有数百个连接突然终止您的数据库，有时需要重新启动或重新启动数据库来纠正这种情况。
例如：您在网站主页上编写了 1 个错误查询，这导致它需要 3 秒而不是 0.3 秒来运行。最终，您的网站在任何时候都运行 1-2 个页面，现在可能会增加到 10-20 个。现在这 10-20 个页面 = 10-20 个 DB 连接不断打开和关闭，平均打开 10-20 个。这个问题会蔓延，使用越来越多的内存，直到达到连接限制（或者更糟糕的是，用完所有内存和现在交换的所有内容）。至此，一切都停了下来。
请记住，连接会占用数据库和应用服务器/池上的资源。当您的数据库正在分页到磁盘时，大多数情况下，在不重置某些内容的情况下进行优雅恢复的所有希望都将失去——显然它可能会发生，但如果没有代码修复，您通常会重新启动以给自己更多时间，直到问题不可避免地出现再次发生，希望到那时，您已经找到错误的查询或错误的配置并修复它。
选项 2 为您提供了最多的选项。这通常不是一个令人头疼的管理问题，但如果你在一台机器上运行它，那么好处是有限的。如果您至少有 2 台机器（应用服务器和数据库服务器），这是一个简单的解决方案，通常可以防止许多系统过载。
【讨论】：
对于用户整天保持连接的公司 Web 应用程序，我可以为每个用户保持一个连接吗？那将是选项四：
【讨论】：