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

Question

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

Теперь у меня есть метод в моем классе DB называется 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

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

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

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

Answer 3

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

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

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

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

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

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

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

Answer 4

Не беспокоить отсоединением , Стоимость проверки $_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 в новой локальной области.
• Тогда ваша функция «disconnect» вызовет mysql_close(), что означает, что PHP A) проверяет, что mysql_close() существует, и B), что вы предоставили все необходимые аргументы mysql_close() и C), что они являются правильным типом (mysql ресурс).

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

Answer 5

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

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

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

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

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

Answer 6

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

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