MySQL PHP - Когда наилучшее время должно разъединиться от базы данных?

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

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

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

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

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

$db->disconnectFromDB();

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

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

Цените занимание время для ответа.

Спасибо!

17
задан alex 5 September 2010 в 23:39
поделиться

6 ответов

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

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

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

24
ответ дан 30 November 2019 в 11:38
поделиться

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

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

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

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

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

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

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

5
ответ дан 30 November 2019 в 11:38
поделиться

Можно хотеть посмотреть на использование постоянные соединения. Вот две ссылки для помощи Вам

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

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

2
ответ дан 30 November 2019 в 11:38
поделиться

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

Обоснование:

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

  • Циклы механизма PHP через внутренний массив подключений mysql
  • Механизм PHP называет mysql_close () внутренне для каждого соединения

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

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

Я не мог бы быть на 100% корректным здесь, но я полагаю, что разногласия находятся в мою пользу.

5
ответ дан 30 November 2019 в 11:38
поделиться

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

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

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

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

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

1
ответ дан 30 November 2019 в 11:38
поделиться

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

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

1
ответ дан 30 November 2019 в 11:38
поделиться
Другие вопросы по тегам:

Похожие вопросы: