PHP mySQL - когда лучше всего отключиться от базы данных?

Насколько мне известно, если вы не используете постоянные соединения, ваше соединение MySQL будет закрыто в конце выполнения страницы.

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

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

Вы можете посмотреть на использование постоянных подключений. Вот две ссылки, которые помогут вам

http://us2.php.net/manual/en/features.persistent-connections.php

http://us2.php.net/manual/en/function.mysql-pconnect.php

Я только что прочитал этот комментарий на веб-сайте PHP относительно постоянного соединения, и было бы интересно узнать:

Here's a recap of important reasons NOT to use persistent connections:

• When you lock a table, normally it is unlocked when the connection closes, but since persistent connections do not close, any tables you accidentally leave locked will remain locked, and the only way to unlock them is to wait for the connection to timeout or kill the process. The same locking problem occurs with transactions. (See comments below on 23-Apr-2002 & 12-Jul-2003)

• Normally temporary tables are dropped when the connection closes, but since persistent connections do not close, temporary tables aren't so temporary. If you do not explicitly drop temporary tables when you are done, that table will already exist for a new client reusing the same connection. The same problem occurs with setting session variables. (See comments below on 19-Nov-2004 & 07-Aug-2006)

• If PHP and MySQL are on the same server or local network, the connection time may be negligible, in which case there is no advantage to persistent connections.

• Apache does not work well with persistent connections. When it receives a request from a new client, instead of using one of the available children which already has a persistent connection open, it tends to spawn a new child, which must then open a new database connection. This causes excess processes which are just sleeping, wasting resources, and causing errors when you reach your maximum connections, plus it defeats any benefit of persistent connections. (See comments below on 03-Feb-2004, and the footnote at http://devzone.zend.com/node/view/id/686#fn1)

(Текст выше написал не я)

Не беспокойтесь об отключении. Стоимость проверки $_connected перед каждым запросом в сочетании со стоимостью фактического вызова $db->disconnectFromDB(); для закрытия в конечном итоге будет дороже, чем просто позволить PHP закрыть соединение, когда оно завершается с каждой страницей.

Рассуждение:

1: Если вы оставите соединение открытым до конца скрипта:

• Движок PHP перебирает внутренний массив соединений mysql
• Движок PHP вызывает mysql_close () внутренне для каждого соединения

2: Если вы закрываете соединение самостоятельно:

• Вы должны проверять значение $_connected для каждого запроса. Это означает, что PHP должен проверить, что переменная $_connected A) существует, B) является логическим значением и C) имеет значение true / false.
• Вы должны вызвать функцию «разъединения», а вызовы функций - одна из самых дорогих операций в PHP. PHP должен проверить, что ваша функция A) существует, B) не является частной / защищенной и C) что вы предоставили достаточно аргументов для своей функции. Он также должен создать копию переменной $ connection в новой локальной области.
• Затем ваша функция отключения вызовет mysql_close (), что означает, что PHP A) проверяет, существует ли mysql_close () и B) что вы предоставили все необходимые аргументы mysql_close () и C), что они являются правильным типом (ресурс mysql).

Возможно, я здесь не на 100% прав, но считаю, что шансы в мою пользу.

Предположительно, основной исполнительной единицей является целый скрипт. В первую очередь вы хотите эффективно и результативно применить ресурсы (то есть базу данных) к единому сценарию.

Однако у PHP, Apache / IIS / чего угодно есть своя собственная жизнь; и они способны использовать связи, которые вы открываете за пределами жизненного цикла вашего сценария. В этом важность постоянных (или объединенных) соединений.

Вернемся к вашему сценарию. Оказывается, у вас есть много возможностей проявить творческий подход к использованию этого соединения во время его выполнения.

Типичный наивный сценарий будет иметь тенденцию снова и снова подключаться к соединению, собирая локально соответствующие фрагменты данных, связанных с заданными объектами / модулями / выбранными параметрами. Именно здесь процедурная методология может наложить штраф на это соединение путем открытия, запроса, получения и закрытия. (Обратите внимание, что любой отдельный запрос будет оставаться активным до тех пор, пока он не будет явно закрыт или пока сценарий не завершится. Обратите внимание, что соединение и запрос - это совсем не одно и то же. Запросы связывают таблицы; соединения связывают ... соединения (в большинстве случаев привязаны к сокетам.) Таким образом, вы должны осознавать необходимость экономии при использовании обоих.

Самая экономичная стратегия в отношении запросов - иметь как можно меньше запросов. Я часто пытаюсь построить более или менее сложный объединенный запрос, который возвращает полный набор данных, а не разбивает запросы на мелкие части.

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

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