持久的数据库连接 – 是或否？
我在一个项目中使用PHP的PDO层进行数据访问，并且我一直在阅读它，并且看到它对持久性数据库连接具有良好的固有支持。 我想知道我是否应该使用它们。 我会看到在一个CRUD沉重的应用程序的性能优势？ 是否有缺点需要考虑，或许与安全有关？
如果对你很重要，我使用MySQL 5.x.
你可以用它作为粗略的“规则集”：
是的 ，使用持久连接，如果：
- 只有less数应用程序/用户访问数据库，即不会导致200个打开（但可能是空闲）连接，因为在同一个主机上有200个不同的用户共享。
- 数据库正在通过networking访问的另一台服务器上运行
- （一个）应用程序经常访问数据库
否 ，不要使用持续连接，如果：
- 您的应用程序只需要每小时访问数据库100次。
- 您有许多Web服务器访问一个数据库服务器
- 您在prefork模式下使用Apache。 它为每个subprocess使用一个连接，可以相当快速地进行升级。 （通过@Powerlord在评论中）
使用持久连接速度要快得多，尤其是在通过networking访问数据库时。 如果数据库运行在同一台计算机上，它并没有太大的区别，但速度还是比较快的。 但是 – 正如名称所述 – 连接是持久的，即保持打开状态，即使未使用。
问题是，在“默认configuration”中，MySQL只允许1000个并行“开放通道”。 之后，新的连接被拒绝（你可以调整这个设置）。 因此，如果您有20个Web服务器，每个客户端上有100个客户端，而且每个客户端每小时只有一个页面访问权限，那么简单的math计算将告诉您需要2000个并行连接到数据库。 这是行不通的。
Ergo：只用于有大量请求的应用程序。
简而言之，我的经验表明，应尽可能避免长久的连接。
请注意，对于使用mysql_pconnect创build的连接，mysql_close是一个无操作（无操作）。 这意味着持久连接不能被客户随意closures。 当连接上没有任何活动发生超过wait_timeout的持续时间时，这种连接将被mysqldb服务器closures。 如果wait_timeout值很大（比如说30分钟），那么mysql数据库服务器可以很容易地达到max_connections的限制。 在这种情况下，MySQL数据库将不会接受任何未来的连接请求。 这是当你的传呼机开始发出哔哔声。
为了避免达到max_connections限制，使用Persistent连接需要仔细平衡以下variables…
1. Number of apache processes on one host 2. Total number of hosts running apache 3. wait_timout variable in mysql db server 4. max_connections variable in mysql db server 5. Number of requests served by one apache process before it is re-spawned 所以，在经过充分的考虑之后，pl使用持续的连接 您可能不想邀请复杂的运行时问题，以获得持久连接的小增益。
创build到数据库的连接是一个相当昂贵的操作。 持续的连接是一个好主意。 在ASP.Net和Java世界中，我们有“连接池”，这是大致相同的事情，也是一个好主意。
海事组织，这个问题的真正答案是最适合你的应用程序。 我会build议你使用永久连接和非永久连接来testing你的应用程序。
8月份的Maggie Nelson @ Objectively Oriented发表了这篇文章， Robert Swarthout做了一些相关的post。 这两个都是不错的读取。
我会问同样的问题，而不是再次提出同样的问题，我只是添加一些我发现的信息。
- PHP的持续连接是邪恶的？
- 持久数据库连接
还值得注意的是，较新的mysqli扩展甚至不包括使用持久数据库连接的选项。
我目前仍在使用persive连接，但计划在不久的将来转变为非持久连接。
在我的愚见：
当使用PHP进行Web开发时，大部分的连接只会在页面执行期间“活”。 持续的连接会花费你很多的开销，因为你必须把它放在会话或一些这样的事情。
99％的时间在页面执行结束时死亡的单个非持续性连接将工作得很好。
另外1％的时间，你可能不应该使用PHP的应用程序，并没有完美的解决scheme。
一般来说，有时候需要使用非持久性连接，并且将单个模式应用于数据库连接devise（只要在上下文中使用持久连接的好处相对较less）是很不错的。
