Важно ли закрывать соединение mysql?

Question

Важно ли закрывать mysql по эффективности или он автоматически закрывается после запуска php-файла?

Answer 1

Из документации :

Примечание. Ссылка на сервер будет закрыта, как только закончится выполнение сценария, если он не был закрыт ранее явным вызовом mysql_close ().

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

Я не уверен, как fastcgi влияет на вещи. Одна страница утверждает, что сборка PHP, поддерживающая fastcgi, создаст постоянные соединения даже для mysql_connect. Это противоречит документации в том смысле, что соединение закрывается, когда завершается процесс, а не сценарий. Вместо того, чтобы проверять это, я рекомендую использовать mysql_close (). На самом деле, я рекомендую использовать PDO , если он доступен.

Answer 2

Это важно? Не так много

Считается ли это хорошей практикой для подражания? Да.

Я не понимаю, почему вы не хотите закрывать это.

Answer 3

При использовании чего-то вроде cgi совершенно не нужно закрывать ваши соединения mysql, так как они автоматически закрываются в конце выполнения скрипта. При использовании постоянных технологий, таких как mod_perl и других, которые поддерживают ваши соединения между запросами, важно отслеживать соединения, глобальные переменные и т. Д.

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

Answer 4

Закрывается, как только скрипт завершает выполнение. Если вы не открыли постоянное соединение. В идеале вы должны освободить ресурс (соединение здесь), как только закончите с ним. Если только не существует большой вероятности, что она понадобится вам снова очень скоро при исполнении.

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

Answer 5

Большинство CMS закрывают соединение MySQL в конце запроса, что на самом деле бессмысленно, потому что PHP все равно сделает это.

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

Теперь много сказано о преимуществах закрытия соединения, но почти ничего не сказано о преимуществах его закрытия. По сути, если вы не закрываете соединение в конце скрипта, тогда вы действительно экономите некоторые ресурсы. Представьте себе веб-приложение (или любое приложение), получающее 100 просмотров страниц в секунду. Таким образом, каждую секунду вам нужно будет вызывать mysqli_close 100 раз - это означает, что каждую секунду у вас есть 100 ненужных обращений к серверу базы данных для закрытия открытых соединений. С точки зрения производительности, это просто накладные расходы, так как PHP будет проверять открытые соединения, когда скрипт все равно будет завершен, и закрывать эти соединения, и это может быть потому, что все происходит так быстро, что PHP не видит, что у вас есть закрыл эти соединения и попытается закрыть их снова.

Примечание: ответ выше предполагает, что вы не используете постоянные подключения (постоянные подключения не используются ни в одной из основных CMS).