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

Question

Я использую Ленивое соединение , чтобы подключиться к моей БД в рамках объекта БД. Это в основном означает, что он не вызывает mysql_connect () до тех пор, пока ему не будет передан первый запрос, и впоследствии он пропускает повторное подключение с тех пор после.

Теперь у меня есть метод в моем классе БД, называемый disconnectFromDB(), который в значительной степени вызывает mysql_close() и устанавливает $_connected = FALSE (поэтому метод query() будет знать, что снова подключится к БД). Должно ли это вызываться после каждого запроса (как частная функция) или извне через объект ... потому что я думал что-то вроде (код только для примера)

$students = $db->query('SELECT id FROM students');

$teachers = $db->query('SELECT id FROM teachers');

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

$db->disconnectFromDB();

Или мне просто включить эту строку выше в самом конце страницы?

Какие преимущества / недостатки есть? Что сработало лучше всего в вашей ситуации? Есть ли что-то действительно плохое в том, что вы забыли закрыть соединение mySQL, кроме небольшой потери производительности?

Цените, что нашли время ответить.

Спасибо!

Answer 1

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

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

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

Answer 2

Не беспокойтесь об отключении. Стоимость проверки $_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% прав, но я считаю, что шансы в мою пользу.

Answer 3

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

Вот резюме важных причин НЕ использовать постоянные соединения:

• Когда вы блокируете таблицу, обычно она разблокируется, когда соединение закрывается, но так как постоянный соединения не закрываются, никаких таблиц вы случайно оставили запертую волю оставаться заблокированным, и единственный способ разблокировать их стоит ждать подключение к таймауту или убить процесс. Та же проблема блокировки происходит с транзакциями. (Увидеть комментарии ниже 23 апреля 2002 года 12-июля-2003)

• Обычно временные таблицы удаляются при закрытии соединения, но так как постоянные связи делают не близко, временные таблицы не так временный характер. Если вы не явно удалить временные таблицы, когда вы сделано, эта таблица уже будет существовать для нового клиента, повторно использующего то же самое подключение. Та же проблема возникает с настройкой переменных сеанса. (Увидеть комментарии ниже 19 ноября 2004 г. 07-Aug-2006)

• Если PHP и MySQL находятся на одном сервере или в локальной сети, время соединения может быть незначительным, в в этом случае нет никакого преимущества постоянные соединения.

• Apache плохо работает с постоянными соединениями. Когда это получает запрос от нового клиента, вместо использования одного из доступных дети, у которых уже есть постоянное соединение открыто, оно стремится породить нового ребенка, который должен затем открыть новое соединение с базой данных. это вызывает избыточные процессы, которые просто спать, тратить ресурсы и вызывая ошибки, когда вы достигнете максимум подключений, плюс это побеждает любая выгода постоянных связей. (См. Комментарии ниже 03 февраля 2004 г., и сноска в http://devzone.zend.com/node/view/id/686#fn1)

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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