Закрытие подключения MySQL в PHP

Использование mysql_close () обычно не требуется, так как непостоянные открытые ссылки автоматически закрываются в конце выполнения скрипта, но также помните о прекращении использования ресурсов, как только они больше не требуются, всегда является хорошей практикой. Если ваш скрипт долго работает на ресурсе, вам больше не нужно просто приближает вас к истощению ресурсов

В любом случае PHP будет выпускать любые ресурсы в конце скрипта.

Например, полезно выделять файловые ресурсы и блокировки файлов, потому что ваш скрипт может работать в форме 1, но вам может понадобиться файл только в течение нескольких мс в самом начале вашего скрипта.

Используя те же рассуждения, если вы используете SQL в течение нескольких мс в начале, тогда выполняете обработку только извлеченных данных – закрывая свое соединение, вы разрешаете другому подключению ваше место (существуют ограничения MySQL, сколько одновременных подключений может быть сделал).

Если, с другой стороны, вы отпустите его в конце скрипта, потому что вы используете БД (с перерывами) во время всего выполнения вашего скрипта, тогда вы просто делаете то, что PHP будет делать в конце сценария.

да, это хорошая практика, чтобы закрыть соединение после использования, это избавит бремя от базы данных. Улучшение улучшится. всегда следует выделять ресурсы после использования, чтобы они могли использоваться другими пользователями.

Если вы имеете в виду использование постоянных соединений: в общем случае (99,99% времени) НЕ (!) Очень разумно использовать постоянные соединения. Конечно, не при использовании транзакций. Снижение производительности при открытии и закрытии соединений по каждому запросу не так уж и велико.

Постоянное соединение PHP плохо, потому что …

• они заставляют транзакции, блокировки таблиц, временные таблицы, переменные сеанса и большинство других полезных функций в MySQL быть очень опасными, что может вызвать сбои в работе сервера и ошибки базы данных во время генерации страницы.
• они занимают сотни сокетов и потоков MySQL, увеличивая риск попадания в какой-либо предел где-то (открытые файлы, настройки mysql, ограничения ядра?).
• Когда что-то ломается из-за постоянных соединений, его, безусловно, очень сложно диагностировать, поскольку он будет отображаться только после того, как определенный поток выполнит определенные запросы в определенном порядке.
• с пулом веб-серверов, один медленный веб-сервер может создавать резервные копии и потреблять столько соединений, которые он не может использовать, чтобы другие серверы не могли создавать подключения для выполнения своих запросов.

См., Например, эту статью.

http://meta.wikimedia.org/wiki/Why_persistent_connections_are_bad

В целом, это хорошая практика программирования, чтобы явным образом освободить все ресурсы, которые вы приобретаете, как можно скорее, так как они могут быть использованы конкурирующими скриптами подпрограмм. Использование конструкторов и деструкторов («умные ресурсы») – хороший способ сделать это. В PHP возможно, что ваш скрипт заканчивается фатальной ошибкой, и в этом случае у вас не будет возможности выпустить их самостоятельно.