Соединение MySql, могу ли я оставить его открытым?
Является ли разумным поддерживать соединение открытым в течение всего сеанса?
Я сделал приложение С#, которое подключается к базе данных MySql, программа читает и записывает ее, и приложение должно работать около 10 часов в день без остановок.
Есть ли риск, связанный с тем, что соединение открыто, а не вызывает функцию close() каждый раз после того, как вы вырвали что-то из базы данных и снова открыли, когда вам нужно что-то новое?
Ответы
Ответ 1
Отключение соединения в течение некоторого времени прекрасное, если:
-
у вас не так много одновременных подключений, которые вы ударили по пределу подключения MySQL;
-
вы не оставляете его открытым в течение нескольких часов, не делая ничего. Соединение MySQL по умолчанию wait_timeout
составляет 8 часов; оставьте соединение неактивным в течение этого времени, и когда вы его придете, вы получите сообщение об ошибке "Сервер MySQL ушел".
Ответ 2
Поскольку вы используете ADO.NET, вы можете использовать встроенные возможности ADO.NET пула соединений. Фактически, позвольте мне уточнить это: вы должны всегда использовать встроенные возможности объединения пула ADO.NET. Поступая таким образом, вы получите среду выполнения .NET, чтобы прозрачно управлять своими подключениями для вас в фоновом режиме. Он будет держать соединения открытыми на некоторое время, даже если вы их закрыли и повторно их используете, если вы откроете новое соединение. Это действительно быстрый материал.
Обязательно укажите в строке подключения, что вы хотите объединить соединения, поскольку это может быть не по умолчанию.
Вам нужно создавать локальные соединения только тогда, когда они вам нужны, поскольку они объединены в backrgound, поэтому нет никаких накладных расходов при создании нового соединения:
using (var connection = SomeMethodThatCreatesAConnectionObject())
{
// do your stuff here
connection.Close(); // this is not necessary as
// Dispose() closes it anyway
// but still nice to do.
}
То, как вы должны это делать в .NET.
Ответ 3
Если приложение использует соединение, нет причин закрывать его. Если вам не требуется соединение, вы должны закрыть его. Если вам нужно подключить несколько приложений к базе данных, у вас есть фиксированное количество подключений к этой базе данных. Вот почему лучше закрыть, когда вы закончите, и снова открыть, когда вам это нужно.
Ответ 4
С точки зрения безопасности, я бы сказал, что лучше закрыть его после запроса, просто чтобы убедиться, что никакая другая программа не может вставлять свои собственные вещи в открытое соединение.
По мере того, как производительность кодируется, очевидно, что лучше всего открыть соединение за все время.
Ваш выбор ^^
Ответ 5
Нет, я не вижу причин, по которым не следует оставлять соединение открытым и повторно использовать его: в конце концов, это все, что связано с различными технологиями пула соединений (которые, как правило, зарезервированы для многопоточные ситуации, когда все работы работают на одном источнике данных).
Но, чтобы расширить ответ на bobince, - просто потому, что вы не закрываете соединение, не предполагайте, что что-то еще не будет: соединение может затягиваться, могут возникнуть проблемы с подключением или сто один причины, по которым ваша связь умирает. Вы должны предположить, что соединение может быть не там, и добавить логику для кода для этого случая исключения.
Ответ 6
На мой взгляд, это не очень хорошая практика, чтобы поддерживать связь.
Другой аспект, который каждый раз говорит о закрытии соединений, - это масштабируемость. Теперь может быть неплохо оставить его открытым, но что делать, если приложение используется дважды в 3 раза больше пользователей. Это боль в шее, чтобы вернуться и изменить весь код. (я знаю, что сделал это: -)
Ответ 7
Ваша проблема будет решена, если вы используете пул соединений в своем коде. Вам не нужно открывать и закрывать соединение, поэтому вы сохраняете драгоценные ресурсы, которые используются при открытии соединения. Вы просто возвращаете соединение в пул, который при запросе на соединение возвращает обратно простоя.
Конечно, я придерживаюсь мнения, получаю экземпляр подключения, использую его, фиксирую/откатываю вашу работу и возвращаю ее в пул. Я бы не советовал держать связь открытой так долго.
Ответ 8
Одна вещь, которую я не видел в других ответах, пока: в случае, если вы подготовили операторы или временные таблицы, они могут блокировать ресурсы сервера до закрытия соединения. Но, с другой стороны, может быть полезно поддерживать связь в течение некоторого времени, а не воссоздавать их каждые несколько мгновений.
Ответ 9
Вы будете платить штраф за производительность, если вы постоянно открываете и закрываете соединения. Возможно, было бы разумно использовать пул соединений и короткий wait_timeout
, если вы обеспокоены тем, что слишком много запущенных копий вашего приложения будут потреблять слишком много соединений с базой данных.
Ответ 10
Да, вы можете, при условии:
- Повторно подключитесь, если вы потеряете соединение
- Вы можете reset состояние соединения, если что-то странное происходит
- Вы обнаружите, что соединение "тихо", например, если происходит тайм-аут брандмауэра
В основном это требует большого внимания к случаям сбоев и правильному восстановлению; частое подключение и разъединение намного проще.
Ответ 11
Я думаю, что если есть механизм объединения соединений, лучше закрыть соединение.
Одна из причин этого заключается в том, что вам не нужно повторно проверять, жив ли ваш канал или нет.