Php 不关闭mysql连接是否有任何可能的负面影响

因此，假设我像往常一样使用php脚本连接到mysql，但是假设我从来没有调用任何代码来关闭该连接，直到页面提供给用户为止

---

有什么理由不让我这么做吗？如果我这样做，可能会产生什么负面后果（如果有的话）

签出php选项

; http://php.net/mysql.allow-persistent
mysql.allow_persistent = On

---

如果您可以设置，这应该会有所帮助。

根据您正在使用的mysql扩展，关闭连接实际上是有益的，因为这将允许使用持久连接。这意味着连接只在脚本第一次运行时打开，并且每次后续运行都会使用已经打开的mysql连接，并根据需要重新连接。这比在每次请求时打开和关闭连接要快一点，资源消耗也要少一点。如果您使用的是

mysqli

，那么持久性连接应该是可能的，并且更可取

即使您的mysql扩展不支持持久性连接，或者没有配置为使用它们，这也只是意味着当脚本退出时连接将关闭，这与您自己关闭连接没有什么不同，这意味着手动关闭连接不会给您带来任何好处

结论：自己关闭连接可能不会给您带来任何好处，实际上可能会影响性能

---

编辑：请参阅

mysql。allow_persistent

和

mysqli。allow_persistent

配置是否为mysql使用持久连接，具体取决于您使用的mysql扩展。

由于PHP具有垃圾收集功能，当脚本在服务器上完成时，连接将关闭。除非您将其指定为持久连接

从php参考中：

通常不需要使用mysql_close（），因为非持久打开的链接会在脚本执行结束时自动关闭

---

您可以在mysql\u close参考中阅读更多内容。

与任何未优化的代码一样，无法关闭（）或杀死（）套接字通常不会变得明显，直到站点/应用程序面临大量需求，即大量页面请求被发送到服务器。通过在请求得到服务后不终止+关闭并释放套接字，套接字会在短时间内处于“等待”状态，从而增加在加载新页面和尝试连接时发生的任何新套接字连接的负载。在流量非常高的情况下，这些套接字将继续在进程内存中累积，可能（根据您的max connections和max_user_connections参数）导致无处不在的“max connections reached…”消息

脚本完成后发生的垃圾收集不一定会回收套接字端点。据我所知，只有在mysqli_close（）之后调用mysqli_kill（）才能真正杀死套接字

---

至于持久连接，您没有提到您正在使用的mysql api或服务器，以及如何将php加载到服务器和网络拓扑中。持久连接允许您避免打开mysql连接的开销。如果mysql与web服务器在同一个机器上运行，那么持久连接可能买不到多少可伸缩性。如果php在cgi进程中运行，则持久连接将不起作用，因为php进程仅在请求的生存期内存在。不要混淆持久连接和JDBC连接池，它们是不同的。

我认为服务器有一个超时值，在这段时间过去后，服务器将关闭连接，而没有任何超时activity@KristerAndersson-这是可能的，但它们不是同一件事。此配置选项似乎适用于MS SQL，而不是MySQL.Grr。。。你编辑了你的答案，但它不会让我取消否决票。“虫子？我想知道，这和什么是一样的吗？”贾里德·法里什——不完全一样。连接池的工作原理稍有不同，因此理论上，只有5个连接的连接池可以服务20个java进程。。。如果连接在池中不可用，则进程只需阻塞（等待）连接即可使用。PHP中的持久连接是类似的，但严格来说每个进程只有一个，所以如果有20个PHP进程，就必须有20个持久连接，并且它们永远不会被共享。谢谢你的详细解释。作为一名基于PHP的“脚本编写者”，我们最近在Atlassian产品（JIRA使用内部群组广告连接器）上遇到了一个问题，其中针对约4000个组和约24000个用户的同步需要约4小时才能使用SSL（否则需要5分钟）。但是，一旦我们将池连接标志传递给JVM，SSL同步时间就会下降到4.5分钟左右。这是一个切线，我知道，但我想知道它是否相似。