Почему это плохая практика, чтобы сделать несколько подключений к базе данных в одном запросе?

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

Кроме того, бросание тонны дополнительных подключений на DB ничего не помогает, если только на сервере DB нет ресурсов, находящихся в режиме ожидания. Если у вас есть 8 ядер и только одно используется для удовлетворения запроса, то, конечно, создание другого соединения может помочь. Однако более вероятно, что вы уже используете все доступные ядра. Кроме того, вы, вероятно, нажмете на один и тот же жесткий диск для каждого запроса DB и добавите дополнительные конфликты блокировки.

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

Это стоимость установки соединения, передачи данных и последующего их разрыва. Это съест вашу производительность.

Доказательства труднее найти, но рассмотрим следующее...

Предположим, что для установления соединения требуется x микросекунд.

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

Теперь предположим, что для закрытия соединения требуется y микросекунд.

Открытие одного соединения займет x+y микросекунд накладных расходов. Открытие многих займет n * (x+y). Это задержит вашу казнь.

Настройка соединения DB обычно довольно тяжелая. Много чего происходит за кулисами (DNS resolution/TCP connection/Handshake/Authentication/Actual Query) .

Однажды у меня была проблема с какой-то странной конфигурацией DNS, из-за которой каждое соединение TCP занимало несколько секунд, прежде чем подняться. Моя процедура входа в систему (из-за сложной архитектуры) заняла 3 различных соединения DB для завершения. С этой проблемой вход в систему занял целую вечность. Затем мы изменили код, чтобы он проходил только через одно соединение.

Мы получаем доступ к Informix из .NET и используем несколько соединений. Если мы не начинаем транзакцию для каждого соединения, она часто обрабатывается в пуле соединений. Я знаю, что это очень специфично для бренда, но большинство(?) доступ cilent систем баз данных будет объединять соединения в меру своих возможностей.

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

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

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

Асинхронные запросы снижают стоимость соединения за счет более быстрого запроса / ответа time...because вы не можете легко достичь этого в PHP без некоторой потоковой обработки, тогда снижение производительности больше, чем просто повторное использование того же соединения.

это мои 2 цента...