Почему внутреннее соединение с фильтрованной таблицей медленнее, чем без фильтрации?

Question

SQL Server 2008 в WINDOWS 2008

Пожалуйста, сравните следующие sqls:

1

select count(*) 
from Trades t 
inner join UserAccount ua on ua.AccID = t.AccID

2.

select count(*) 
from Trades t 
inner join (
    select * 
    from UserAccount ua 
    where ua.UserID = 1126
) as theua on theua.AccID = t.AccID

3.

select count(*) 
from Trades t 
inner join UserAccount ua on ua.AccID = t.AccID 
where ua.UserID=1126

Данные сделки содержат миллионы строк, а UserAccount - довольно маленькая таблица. И AccID может быть дублирующим.

Результат выполнения:

1. 234734792
2. 8806144
3. 8806144

Я ожидаю, что № 2 может быть по крайней мере так же быстро, как № 1, но на самом деле это намного медленнее, даже медленнее, чем № 3 Потребление времени:

1. 2 с
2. 10 секунд
3. 8 секунд

Может ли кто-нибудь объяснить причину? И можно ли сделать это быстрее, когда мне нужен фильтр типа UserID = 1126?

Answer 1

1. - самый быстрый, так как в нем меньше всего условий.
   (Отсутствует идентификатор пользователя)

2. является самым медленным, потому что он имеет внутренний выбор, который должен выполняться для каждого соединения
   ( кстати: никогда не делай этого )

3. медленнее, чем # 1, из-за дополнительного условия where (UserID). Это запрос, который вы хотите использовать.
   (Вы также можете поменять местами «где» для «и» сразу после объединения)

У вас есть внешние ключи настроены?

Также убедитесь, что у вас есть соответствующие Индексы (IE: AccID & UserID).

В SSMS запустите запрос с включенным Планом выполнения , и он покажет вам потенциальную неэффективность в запросе / индексах, которые вы должны создать.

В плане выполнения вы должны следить за такими вещами, как таблицы сканы . То, что вы хотите увидеть: ищет .