为什么在一个请求中建立多个数据库连接是一种不好的做法？

题

关于单例的讨论 PHP 让我越来越思考这个问题。大多数人指示您不应在一个请求中建立一堆数据库连接，我只是好奇您的推理是什么。我的第一个想法是你的脚本向数据库发出这么多请求的费用，但后来我反问自己一个问题：多个连接不会使并发查询更加高效吗？

一些知情人士的答案（有证据，伙计们）怎么样？

解决方案

数据库连接是有限的资源。有些数据库的连接限制非常低，浪费连接是一个主要问题。通过消耗大量连接，您可能会阻止其他人使用数据库。

此外，除非数据库服务器上有资源闲置，否则向数据库添加大量额外连接并没有任何帮助。如果您有 8 个核心，但只有一个用于满足查询，那么当然，建立另一个连接可能会有所帮助。不过，更有可能的是，您已经在使用所有可用的内核。您还可能会为每个数据库请求访问相同的硬盘驱动器，并添加额外的锁争用。

如果您的数据库具有类似高利用率的情况，那么添加额外的连接将无济于事。这就像在应用程序中产生额外的线程，盲目地希望额外的并发性将使处理速度更快。它可能在某些情况下，但在其他情况下，它只会减慢您的速度，因为您会破坏硬盘驱动器，浪费时间进行任务切换，并引入同步开销。

其他提示

这是建立连接、传输数据然后断开连接的成本。它会消耗你的表现。

证据很难获得，但请考虑以下因素......

假设建立连接需要 x 微秒。

现在您想要发出多个请求并来回获取数据。假设一个连接和多个连接之间的传输时间差异可以忽略不计（只是为了争论）。

现在假设关闭连接需要 y 微秒。

打开一个连接将花费 x+y 微秒的开销。打开许多将需要 n * (x+y)。那会延迟你的执行。

设置数据库连接通常非常繁重。后台正在发生很多事情 （DNS解析/TCP连接/握手/认证/实际查询）.

我曾经遇到过一些奇怪的 DNS 配置问题，导致每个 TCP 连接都需要几秒钟才能建立。我的登录过程（由于架构复杂）需要 3 个不同的数据库连接才能完成。由于这个问题，登录需要很长时间。然后我们重构了代码，使其仅通过一个连接。

我们从 .NET 访问 Informix 并使用多个连接。除非我们在每个连接上启动一个事务，否则它通常是在连接池中处理的。我知道这是非常特定于品牌的，但大多数（？）数据库系统的客户端访问将尽其所能地汇集连接。

顺便说一句，由于跨数据库连接，我们确实遇到了连接计数问题。Informix 支持同义词，因此我们对常见的罪犯进行了同义词处理，并且多个连接在服务器端进行处理，从而节省了大量传输时间、连接创建开销以及（我们情况的真正关键）许可费用。

我认为这是因为您的请求不是异步发送的，因为您的请求是在服务器上迭代完成的，每次都会阻塞，当您只需要这样做时，您必须支付每次创建连接的开销一次...

在 Flex 中，所有 Web 服务调用都会自动异步调用，因此您经常会看到多个连接或在同一连接上排队的请求。

异步请求通过更快的请求/响应时间来降低连接成本......因为你不能 容易地 在 PHP 中实现这一点而不需要一些线程，那么性能损失比简单地重用相同的连接更大。

这是我的2分钱...

许可以下： CC-BY-SA 和归因