> Что лучше: выбрать из базы одним запросом тысячу id или сделать тысячу запросов по одному id (Go)

Однозначно лучше выбрать из базы одним запросом тысячу id. Тысяча отдельных запросов - это классический антипаттерн N+1, который приводит к катастрофической деградации производительности.

Почему один запрос лучше:

• Сетевые задержки: Каждый запрос требует установки соединения (или использования пула), передачи данных по сети и получения ответа. Тысяча запросов - это тысяча round-trip'ов, каждый добавляет минимум 0.5-2 мс задержки, что даёт 0.5-2 секунды только на сеть.
• Нагрузка на БД: База данных тратит ресурсы на парсинг, планирование и выполнение каждого отдельного запроса. Один запрос с WHERE id IN (...) или JOIN выполняется как одна транзакция, используя индексы и кеш страниц эффективно.
• Транзакционная изоляция: При тысяче запросов сложнее гарантировать консистентность данных (например, если между запросами данные изменятся). Один запрос даёт атомарный срез.

Когда тысяча запросов может быть оправдана (редкие случаи):

• Если каждый id обрабатывается в отдельном микросервисе или внешнем API, и база - лишь часть пайплайна.
• Если список id динамический и формируется на основе результатов предыдущих запросов (но это уже не "просто выборка").
• При работе с очень большими наборами данных (миллионы id), где один запрос может переполнить память или привести к блокировкам - тогда применяют пагинацию или курсоры, но не тысячу отдельных запросов.

В Go это особенно критично: горутины позволяют легко написать конкурентные запросы, но это не решает проблему сетевых задержек и нагрузки на БД. Пример плохого кода:

GO
for _, id := range ids {
    go func(id int) {
        row := db.QueryRow("SELECT ... WHERE id = $1", id)
        // ...
    }(id)
}

Лучше:

GO
rows, err := db.Query("SELECT ... WHERE id = ANY($1)", pq.Array(ids))

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