In the manual, the connection is closed after each query is completed. So when there are multiple database operations, this will lead to continuous generation and release of connections, isn't it unreasonable? For example, there is a. php with 20 functions, and 20 objects need to be instantiated respectively. each object has database operations .... In the manual, the connection is closed after each query is completed. So when there are multiple database operations, this will lead to continuous generation and release of connections, isn't it unreasonable?
For example, there is a. php with 20 functions, and 20 objects need to be instantiated respectively. each object has database operations.
There are three methods:
1. obtain a database connection from each class of 20 objects. The operation is completed and disabled.
2. get the database connection in a. php. in each function, pass the connection parameter in and release it in a. php.
3. generate a static database connection object. each class calls ConnectionClass: db
For more information, see.
.
Reply content:
In the manual, the connection is closed after each query is completed. So when there are multiple database operations, this will lead to continuous generation and release of connections, isn't it unreasonable?
For example, there is a. php with 20 functions, and 20 objects need to be instantiated respectively. each object has database operations.
There are three methods:
1. obtain a database connection from each class of 20 objects. The operation is completed and disabled.
2. get the database connection in a. php. in each function, pass the connection parameter in and release it in a. php.
3. generate a static database connection object. each class calls ConnectionClass: db
For more information, see.
.
You can save the database connection with a static variable to connect multiple functions in a request to the database only once.
If persistent connections are enabled, a PHP-FPM process can share a database connection in multiple requests.
Query ('select * FROM table1')-> fetch_all ();} function foo2 () {return db ()-> query ('select * FROM table2 ') -> fetch_all ();} var_export (foo1 (); var_export (foo2 ());
@ Impig33 the following two function calls return the same results. it can be seen that after $ db is assigned a value for the first time, the branch in else will not be executed for the second time and will not be regenerated into a uniqid number.
I don't know about other databases. MySQL supports persistent connections.
Persistent connection does not close the previous database connection. The previous connection is used directly during the next connection.
MySQLi:There are no MySQL-likepconnect()
Function, but you can addp:
, Refer to the PHP official website: mysqli extension and persistent connection. Thank you @ eechen for your correction.
Unlike mysql extensions, mysqli does not provide a special method to open persistent connections. To open a persistent connection, you must add p: before the host name during connection :.
PDO also supports persistent connections: used in the 4th new PDO parametersarray(PDO::ATTR_PERSISTENT
), Refer to the PHP official manual-PDO connection and connection management Example4.
3. you do not need to discuss this. Generally, Db objects adopt the single-piece mode, which is already a consensus.
I personally think 2 is the best.
You can also consider using the connection pool.
Https://www.baidu.com? Wd = ph...
I also think it is better to support Singleton mode.
I don't know how to write this answer.
A bunch of things: objects, destructor, Singleton, dependency injection, persistent connections
In the end, I suddenly thought it was not difficult. I had to find a framework for analysis, such as phalcon.