在 AJAX 调用中使用 mysql_pconnect 时还需要注意什么
我构建了一个应用程序（MySQL/PHP），它（及时）可能会使用到远程（可能很慢）MySQL 服务器的连接。该应用程序使用 AJAX 耳语，频繁打开数据库连接。我已经做了一些客户端优化，但从未有足够的勇气使用持久连接，这可能是个好主意。
我担心空闲的 mysql 连接可能会超出服务器限制，导致需要重新启动服务器。所以我打算使用mysql.connection_timeout为15s，这会杀死限制后的每个空闲持久连接？或者它会阻塞系统资源直到服务器进程结束吗？
我不会在私语中使用事务，并且每个锁都应该在连接关闭后释放，对吧？
还有其他我应该注意的持久连接问题吗？ （我已经阅读了文档。）
I build an application (MySQL/PHP) which (in time) may use connections to distant (and maybe slow) MySQL servers. The app uses AJAX whispers which open the DB connections frequently. I have done some client side optimization, but never had courage enough to use persistent connections, which may be good idea here.
I am worried about idle mysql connections which may exceed the server limit resulting in need to restart the server. So I plan to use mysql.connection_timeout to 15s, which will kill every idle persistent connection after the limit? Or will it block system resources until the end of times of server process?
I won't use transactions in whispers and every lock should be released after the connection is closed, right?
Are there any other persistent connection issues I should be aware of? (I have read the documentation already.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
使用 MySQL 的持久连接通常不会获得任何好处。它的连接协议通常已经相当快了。当您使用常规非持久连接时，您所失去的是“干净”操作环境的保证。
如果您的任何脚本在事务过程中因任何原因死亡或保留服务器端变量设置，则持久连接意味着当其他脚本再次拾取连接时，完成一半的事务仍然处于活动状态。
当这种情况发生时，你很容易陷入僵局。新脚本不知道它有一个旧的/脏的连接，并且MySQL无法看到原始的连接脚本已经消失并进行自己的清理，因此您最终会遇到一个垃圾遍地的环境。
话虽这么说，您可以使用
mysql.max_persistent设置来限制 PHP 代表您保持打开的连接数量。无论您尝试从脚本建立多少个连接，PHP 都不会超过该限制，因此您可以将其设置为低于 MySQL 自己的max_connections设置。You don't generally gain anything by using persistent connections with MySQL. Its connection protocol is already generally fairly fast. What you do lose is the guarantee of a "clean" operating environment when you use regular non-persistent connections.
If any of your scripts die for any reason while in the middle of a transaction or leave server-side variables set, a persistent connection means that half-done transaction is still active when the connection is picked up again by some OTHER script.
You can quite easily fall into a deadlock situation when this happens. The new script has no idea that it's got an old/dirty connection, and MySQL cannot see that the original connecting script has gone away and do its own cleanup, so you end up with a garbage strewn environment.
That being said, you can limit how many connections PHP will keep open on your behalf with the
mysql.max_persistentsetting. No matter how many connections you attemp to make from your scripts, PHP will never exceed that limit, so you can set it to be lower than MySQL's ownmax_connectionssetting.