PHP Lang
  1. PHP Lang
  3. PHP mySQL – Когда самое лучшее время для отключения от базы данных?
Intereting Posts
Вход в Facebook для участников группы Symfony, как использовать событие формы для проверки динамической клиентской формы Уникальное ограничение, как избежать дубликатов Контроллер Laravel 5, отправляющий целое число JSON в виде строки как объявить php-класс с именем переменной как синхронизировать шифрование между delphi и php, используя dcpcrypt php получает текущее время US / Eastern Laravel 4 – Выбрать похожие модели PDOException: SQLSTATE 01002 Не удалось подключиться к адаптивному серверу (степень 9) Обновление свойств объекта в веточке Codeigniter update_batch не работает Сравнение условий сборки для оператора if Ошибка вычисления float PHP при вычитании Как правильно настроить обработчик исключений в Zend? JW Player читается с php

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

Я использую ленивое соединение для подключения к моей БД в моем объекте БД. Это в основном означает, что он не вызывает 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, помимо небольшой потери производительности?

Цените свое время, чтобы ответить.

Спасибо!

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

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

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

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

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

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

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

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

  • Apache не работает с постоянными соединениями. Когда он получает запрос от нового клиента, вместо использования одного из доступных дочерних элементов, у которого уже открыто постоянное соединение, он имеет тенденцию порождать нового ребенка, который должен затем открыть новое соединение с базой данных. Это приводит к избыточным процессам, которые просто спят, тратят ресурсы и вызывают ошибки при достижении максимальных подключений, а также при любых преимуществах постоянных соединений. (См. Комментарии ниже, 03-Feb-2004, и сноску на 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% прав, но я считаю, что шансы в мою пользу.

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

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

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

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

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

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

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

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

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

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