Db производительности: несколько соединений против присоединяется/подзапросы

Question

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

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

2. Пакет команд вместе (что означает только одно соединение, но больше объединений/подзапросов в реальных запросах).

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

Я использую SQL Server 2008, но я предполагаю, что этот вопрос должен быть общим для большинства платформ db (?).

EDIT: Я знаю, что это очень общий вопрос, и поэтому я ищу общий ввод/ответы.

Answer 1

На этот вопрос действительно нет единого ответа.

Иногда лучше, чтобы написать несколько простых запросов, чтобы получить результат пошагово, как вы описываете в 1.

Иногда лучше написать сложный SQL запрос, как и в 2, и пусть оптимизатор РСУБД»решить, как получить результат наиболее эффективно.

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

В SQL Server 2008 есть инструменты, помогающие анализировать запросы и давать рекомендации по оптимизации производительности.

Answer 2

Я бы избегал чат-дизайна (несколько поездок по нескольким DB) в максимально возможной степени. Сетевая латентность - такой убийца производительности, который, учитывая два варианта, которые вы предоставили, вариант № 2 - это простой выбор. Тем не менее, я предполагаю, что соединения/подзапросы не являются необычными.