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