Home » Php » PHP MySQL connection persistence

PHP MySQL connection persistence

Posted by: admin July 12, 2020 Leave a comment


I’ve read a ton about persistent database connections between PHP and MySQL (mysql_connect vs. mysql_pconnect). Same with PDO and MySQLi. It’s definitely just my lack of understanding on this one, but how can a database connection be persistent between webpages? In this code:

$conn = mysql_pconnect( $server , $user, $pass );
mysql_select_db( $dbname );

If two users load this page at the same time, with two different $dbname variables, will PHP only make one connection to the database or two? I am fairly certain that

$conn = mysql_connect( $server , $user, $pass );

would make two connections.

If pconnect reuses the connection opened by the first user, will the mysql_select_db call work for the second user?

Ideally, what I am looking for is a way to have fewer database connections but still be able to set the default database in each PHP script. I have clients who all use the same PHP scripts, but the data is stored in their own client database (hence, $dbname is always different, but the MySQL connection parameters are the same – same mysql ip address, user and password).

Hope that makes sense. We can use MySQL, MySQLi or PDO, just need to know how to accomplish this the best way without having the possibility for clients to accidently write data to someone else’s database! Thanks in advance.

How to&Answers:

From my reading of documentation and comments, I see:

Docs on mysql_pconnect (deprecated method)

Second, the connection to the SQL server will not be closed when the execution of the script ends. Instead, the link will remain open for future use ( mysql_close() will not close links established by mysql_pconnect()).

and a comment on that page

Persistent connections work well for CGI PHP managed by fastCGI, contrary to the suggestion above that they only work for the module version. That’s because fastCGI keeps PHP processes running between requests. Persistent connections in this mode are easily made immune to connection limits too, because you can set PHP_FCGI_CHILDREN << mysql’s max_connections <<< Apache’s MaxClients. This also saves resources.

Docs on mysqli_connect (new method)

Prepending host by p: opens a persistent connection. mysqli_change_user() is automatically called on connections opened from the connection pool.

Docs for mysqli_change_user:

Changes the user of the specified database connection and sets the current database.

So my understanding is as follows: pconnect keeps the connection open after a script ends but while a process (or maybe group of processes) is still alive (like in a server with FCGI set up). Only one script at a time uses a connection, and when a new script grabs that connection the user and database are updated.

Thus if you use FCGI and persistent connections you can reduce the number of db connections open, but scripts running simultaneously will not be sharing the same connection. There is no problem with the connection being confused as to which database is selected.


The persistence is done by the copy of the PHP that’s embedded in the webserver. Ordinarily you’d be right- if PHP was running in CGI mode, it would be impossible to have a persistent connection, because there’d be nothing left to persist when the request is done and PHP shuts down.

However, since there’s a copy of PHP embedded in the webserver, and the webserver itself keeps running between requests, it is possible to maintain a pool of persistent connections within that “permanent” PHP.

However, note that on Apache multi-worker type server models, the connection pools are maintained PER-CHILD. If you set your pool limit to 10, you’ll have 10 connections per Apache child. 20 children = 200 connections.

Persistent connections will also lead to long-term problems with deadlocks and other hard-to-debug problems. Remember – there’s no guarantee that a user’s HTTP requests will be serviced by the SAME apache child/mysql connection. If a script dies part-way through a database transaction, that transaction will NOT be rolled back, because MySQL does not see the HTTP side of things – all it sees is that the mysql<->apache connection is still open and assumes all’s well.

The next user to hit that particular apache/mysql child/connection combination will now magically end up in the middle of that transaction, with no clue that the transaction is open. Basically, it’s the Web equivalent of an unflushed toilet – all the “garbage” from the previous user is still there.

With non-persistent connections, you’re guaranteed to have a ‘clean’ environment each time you connect.