Ваш вопрос очень расплывчатый и, похоже, перепутал терминологию.
Количество строк, полученных из набора результатов, не влияет на количество соединений. Также не выполняется какое-либо отношение к соединениям.
(Если это не очень плохо написано приложение, которое штампует соединения, подключения и отключения от базы данных для каждого выполнения оператора.)
Я думаю, что вы спрашиваете, существует ли «туда и обратно» сделал на сервер базы данных для каждой «выборки», чтобы получить строку из набора результатов, возвращаемого запросом SELECT.
Ответ на этот вопрос нет, большинство библиотек баз данных получают «пакет» строк. Когда клиент запрашивает следующую строку, он возвращается из набора, уже возвращенного библиотекой. Как только партия исчерпана, это еще один раунд, чтобы получить следующий набор. Это все «под обложками», и ваше приложение не нуждается в этом.
Не имеет значения, извлекаете ли вы только одну строку, а затем отбрасываете набор результатов или выполняете ли вы [через и извлекаете каждую строку. Это та же картина.
С точки зрения производительности и масштабируемости, если вам нужно всего лишь извлечь четыре строки, тогда нет смысла готовить набор результатов, содержащий больше, чем это. Когда ваш запрос выполняется против базы данных, сервер базы данных генерирует набор результатов и удерживает это, пока клиент не запросит строку из набора результатов. Большие результаты требуют больше ресурсов на сервере базы данных.
Огромный набор результатов потребует большего количества обращений к серверу базы данных, чтобы получить все строки, чем меньший набор результатов.
Это не только количество строк, но и размер возвращаемой строки. (Именно поэтому типы DBA захватывают запросы разработчиков, которые выполняют запрос SELECT * FROM, чтобы получить каждый столбец переворачивания, когда клиент фактически использует только небольшое подмножество столбцов.)
Сокращение обращений к базе данных обычно повышает производительность, особенно если клиент подключается к серверу базы данных по сетевому соединению.
Но нам не нужно беспокоиться о том, сколько круговых запросов требуется для извлечения всех строк из набора результатов ... оно берет то, что требуется, клиент нуждается в том, что ему нужно.
То, что мы должны быть обеспокоены этим количество запросов мы бежим
выполнение запроса является намного больше, накладными расходами, чем просто туда и обратно для выборки. Оператор SQL должен быть проанализирован для синтаксиса (порядок и шаблон ключевых слов и идентификаторов верны), для семантики (идентификаторы ссылочных допустимых таблиц, столбцов, функций и пользователя должны иметь соответствующие разрешения для объектов базы данных), генерировать план выполнения (оценить, какие предикаты и операции могут быть удовлетворены с помощью индексов, перестановки для порядка выполнения операций). Наконец, оператор может быть выполнен, и если возвращается результат, подготовьте его, а затем сообщите клиенту о состоянии завершения запроса и дождитесь, когда клиент запросит строки из набора результатов, когда клиент закроет набор результатов, база данных сервер может очистить, освободить память и т. д.
Большинство API-интерфейсов баз данных имеют вызов «connect», который открывает соединение с базой данных, а затем все происходит в том же соединении. – Barmar
Если вы используете API OO, например PDO, каждый экземпляр класса базы данных соответствует соединению с базой данных. – Barmar