Mysql_pconnect is used to establish a persistent connection between php and mysql. Generally, the execution mode of php is to initialize all resources when the script starts to be executed, and release all resources after the script ends. This is not the case with mysql_pconnect. Every time mysql_connect re-establishes a relationship with the SQL server through tcp or unix domian socket, each handshake consumes a lot of server resources.
When pconnect is used and a request is sent to connect to mysql, php checks whether there is an identical connection (connected to the same mysql server with the same user name and password, if yes, use this connection directly. It is worth noting that the same connection concept is for the process. Multiple connections will be established when different processes call mysql_pconnect.
Connect and pconnect do not bring about functional differences, but only performance differences.
Generally, php runs in two modes: cgi and apache. As a cgi, connect is no different from pconnect, because every time cgi is run, resources are destroyed and cleared.
Php can be used for continuous database connection when running as an apache module, but there may be potential problems.
Assume that the mysql server is configured to support a maximum of 10 concurrent jobs. Apache is configured to use 100 sub-processes.
Apache is coordinated by a parent process to distribute the received http request to the idle sub-process for processing. As a result, it quickly processes 10 http requests, assuming that 10 of them are allocated to different sub-processes, the persistent connections between the 10 and mysql are established, and the mysql capability has reached the limit. At this time, an http request is sent. apache assigns it to any other process that is not in the 10 sub-processes. Then, there is no way for this process to establish a connection to mysql, because the slot is full.
Other problems may occur when using persistent connections.
If a persistent connection is used in your script and the table Lock operation is performed, if the script is not unlocked by the end of the script. If you run this script again next time, it will wait for its unlock table to get the lock table, and it will no longer be able to come back in the past, which becomes an endless loop. Unless you restart the web or mysql server. The other cause is the transaction.
To avoid this problem, you can use register_shutdown_function to register a callback function. In this case, release the table lock or roll back the transaction.