There's nothing here about connexions automatically claused at the end of a script. About that, a little note from devzone.zend.com :
"Open connections (and similar resources) are automatically destroyed at the end of script execution. However, you should still close or free all connections, result sets and statement handles as soon as they are no longer required. This will help return resources to PHP and MySQL faster."
mysqli_close -- mysqli->close — Fecha uma conexão aberta anteriormente com o banco de dados
Estilo de procedimento:
Estilo orientado a objeto (metodo):
A função mysqli_close() fecha uma conexão com um banco de dados aberto
anteriormente especificado pelo parâmetro
Valores de retorno
TRUE em caso de sucesso ou
FALSE em caso de falha.
I've had situations where database connections appeared to persist following php execution. So, now, my __destructor function explicitly contains a $cxn->close(). It hurts nothing, and helps avoid memory leaks.
The mysqli_close() function and object method only remove the ability to use the mysql object again in the script, essentially on the surface only nulling out all object parameters.
At least with PHP5.3.2 and Windows connecting by tcp, this differs by the old mysql_close() function in that it does not actually close out the tcp socket being used. You should always use mysqli_kill() function before mysqli_close() to actually close and free up the tcp socket being used by PHP. Garbage collection after script execution nor mysqli_close() do not kill the tcp socket on their own. The socket would otherwise remain in 'wait' state for approximately 30 seconds, and any additional page loads/connection attempts would only add to the total number of open tcp connections. This wait time does not appear to be configurable via PHP settings.
Also as of this version, mysqli created links cannot be "deactivated", and will continue to accumulate in process memory until the PHP server or process is restarted, essentially making mysqli.max_links = -1 required.