Что быстрее, ссылка на свойство во внешней таблице или сравнение с параметром?

Question

Я понимаю, что этот пример полностью надуман, но я ищу здесь общее правило; есть ли разница с точки зрения производительности между этими двумя запросами?

Пример 1: Справочная внешняя таблица:

select o.id, o.name,
(select count(*) from inner_table i1 where i1.outerid = o.id),
(select sum(i2.amount) from other_inner_table i2 where i2.outerid = o.id)
from outer_table o
where o.id = @outerid

Пример 2. Сравнение напрямую с параметром:

select o.id, o.name,
(select count(*) from inner_table i1 where i1.outerid = @outerid),
(select sum(i2.amount) from other_inner_table i2 where i2.outerid = @outerid)
from outer_table o
where o.id = @outerid 

В основном я использую Sql Server 2008 R2, но мне были бы интересны ответы, специфичные для любой RDMS.

Обновление:

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

Answer 1

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

CREATE TABLE [dbo].[inner_table](
    [outerid] [int] NOT NULL
)
CREATE TABLE [dbo].[other_inner_table](
    [outerid] [int] NOT NULL,
    [amount] [int] NOT NULL
)
CREATE TABLE [dbo].[outer_table](
    [id] [int] NOT NULL,
    [name] [varchar](30) NOT NULL
)

Затем я включил планы выполнения и выполнил оба запроса.В обоих случаях это показало, что все 3 таблицы были отсканированы (как и ожидалось, без / с низкими строками).В частности, сканирование по inner_table имеет предикат:

[DBName].[dbo].[inner_table].[outerid] as [i1].[outerid]=[@outerid]

, а сканирование по other_inner_table имеет предикат:

[DBName].[dbo].[other_inner_table].[outerid] as [i2].[outerid]=[@outerid]

То есть в первомНапример, оптимизатор определил, что условие внешних условий where в where o.id = @outerid подразумевает, что в подзапросах o.id всегда равно @outerid, и выполнил эту замену.

В общем, если толькоесть проблема с производительностью, вы не должны пытаться «помочь» SQL, преобразовывая запросы вручную.Имеется что-то вроде 300 различных оптимизаций, которые оптимизатор имеет в своем распоряжении - вы можете не выбрать лучший (ие).

Answer 2

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

Answer 3

Нет простого способа ответить на этот вопрос;как выглядят ваши индексы?ограничения?статистика?Как распределяются данные по i2.outerid?Сколько оперативной памяти у вас на сервере?

Иногда настройка производительности - это наука;обычно это вуду.:)