niskiej zapytanie wydajności podczas używania zmiennych bazy

Question

I przy użyciu kolejnych zapytań ekstrakcji górne 100 i 101 linii z dB gettings następujące upływający czas, który całkowicie różni się (drugie zapytanie ~ 8 wolniej niż pierwszy)

SELECT TOP (100) * 
FROM PhotoLike WHERE photoAccountId=@accountId AND accountId<>@accountId 
ORDER BY createDate DESC 
GO 

SQL Czasy wykonania serwera: Czas procesora = 187 ms, czas, który upłynął = 202 ms.

SELECT TOP (101) * 
FROM PhotoLike WHERE photoAccountId=@accountId AND accountId<>@accountId 
ORDER BY createDate DESC 
GO 

SQL Server Execution Times: czas CPU = 266 ms, czas, jaki upłynął = 1644 ms.

Plan Wykonanie pierwszych dwóch przypadkach:

Ale gdybym pozbyć zmiennej @accoundId, mam następujące wyniki, co w przybliżeniu równa się szybciej i więcej niż 2 razy niż pierwszego zapytania z tym pytaniem.

SELECT TOP (100) * 
FROM PhotoLike WHERE photoAccountId=10 AND accountId<>10 
ORDER BY createDate DESC 
GO 

SQL Server Execution Times: czas CPU = 358 ms, czas, jaki upłynął = 90 ms.

SELECT TOP (101) * 
FROM PhotoLike WHERE photoAccountId=10 AND accountId<>10 
ORDER BY createDate DESC 
GO 

SQL Server Execution Times: czas CPU = 452 ms, czas, jaki upłynął = 93 ms.

Plan Wykonanie drugich dwóch przypadkach:

Dlaczego tak się stało i jak mogę poprawić wydajność z varibales?

UPDATE

Dodane plany wykonania.

Answer 1

Jest tu kilka rzeczy.

Gdy używasz zmiennych SQL Server nie wykrywa w ogóle wartości, chyba że dodasz także OPTION (RECOMPILE).

Wartość szacunkowa liczby rzędów pasujących do photoAccountId=@accountId jest znacznie mniejsza w porównaniu z przypuszczeniami, niż ma to miejsce w rzeczywistości. (Zauważ, że gruby wiersz wychodzący z indeksu poszukuje w drugim planie, a decyzja o zastosowaniu planu równoległego).

także TOP 100/TOP 101 jest cut off point między TOP N sortowania za pomocą algorytmu, który po prostu potrzebuje miejsca do sortowania 100 wierszy i to robi pełną rodzaju .. The niedokładne oszacowanie liczba wierszy prawdopodobnie oznacza, że ​​jest za mało pamięci przydzielone do pełnego sortowania i rozlewa się na tempdb.

Po prostu dodanie OPTION (RECOMPILE) do zapytania ze zmiennymi prawdopodobnie trochę poprawi sytuację, choć wygląda na to, że nawet "szybki" plan przeprowadza wiele kluczowych wyszukiwań, których można uniknąć za pomocą różnych indeksów.

Answer 2

Zastanawiam się, czy może to być związane z sniffingiem parametrów. Jak szybko działa następująca kwerenda?

DECLARE @accountIdParam int; 
SELECT @accountIdParam = @accountId; 

SELECT TOP (101) * 
FROM PhotoLike WHERE photoAccountId=@accountIdParam AND accountId<>@accountIdParam 
ORDER BY createDate DESC 
GO 

Answer 3

Mogę, powinieneś utworzyć indeks klastrowy w oparciu o pole accountId twojej tabeli.

Jak przetestować nierówności, powinno być bardziej wydajnych.

tworzyć unikalne klastrowych INDEX [IX_MyIndexName] ON [dbo] [PhotoLike] ( accountid DESC, CreateDate DESC, photoAccountId DESC, )