Do czego służy opcja OPTION FAST w instrukcji SELECT?

Zrobiłem trochę kopania tego, co OPTION (FAST XXX)podpowiedź kwerendy robi w SELECTinstrukcji i wciąż jestem z niej zagubiony. Według MSDN:

Określa, że ​​zapytanie jest zoptymalizowane pod kątem szybkiego pobierania pierwszych strzałek numerycznych. Jest to nieujemna liczba całkowita. Po zwróceniu pierwszych strzałek numerycznych zapytanie kontynuuje wykonywanie i generuje pełny zestaw wyników.

Dla mnie to nie ma większego sensu, ale w zasadzie zapytanie może uzyskać pierwsze XXX wierszy naprawdę szybko, a pozostałe z normalną prędkością?

Zapytanie Microsoft Dynamics, które skłoniło mnie do zastanowienia się nad tym, to:

select pjproj.project,pjproj.project_desc,pjproj.customer,pjproj.cpnyid
from pjproj WITH (NOLOCK)
where project like  '%'
order by project OPTION(FAST 500)

Czy ktoś może dokładnie wyjaśnić, na czym polega ta wskazówka dotycząca zapytania, i że ma przewagę nad nieużywaniem?

FAST NPowie SQL Server wygenerować plan wykonania z szybko wraca liczbę wierszy określanych jako N.

Zauważ, że szacunki będą zgodne z tym, Nponieważ mówisz serwerowi SQL, aby Njak najszybciej pobierał wiersze.

np. uruchamianie poniżej zapytania z fast 500:

-- total rows : 19972
 SELECT [BusinessEntityID]
      ,[TotalPurchaseYTD]
      ,[DateFirstPurchase]
      ,[BirthDate]
      ,[MaritalStatus]
      ,[YearlyIncome]
      ,[Gender]
      ,[TotalChildren]
      ,[NumberChildrenAtHome]
      ,[Education]
      ,[Occupation]
      ,[HomeOwnerFlag]
      ,[NumberCarsOwned]
  FROM [AdventureWorks2012].[Sales].[vPersonDemographics]
  order by BusinessEntityID
  option (fast 500)

Szacunki vs Rzeczywiste wiersze z option (fast 500)

Szacunki vs Rzeczywiste wiersze bez option (fast 500)

Przypadek użycia będzie, gdy aplikacja robi buforowania (obciążenie dużą ilość danych w tle) i chce pokazać użytkownikowi kawałek danych tak szybko, jak to możliwe.

Innym interesującym przypadkiem zastosowania jest ląd SSIS, który Rob Farley opisuje FAST Njako katalizator przyspieszający odzyskiwanie danych.

Dodając tę ​​wskazówkę, poczułem, jakby magiczna różdżka została machnięta w poprzek zapytania, aby działało kilka razy szybciej.

Zobacz także odpowiedź Remusa Rusanu .

Podczas korzystania z podpowiedzi zapytania OPCJA (SZYBKA n) optymalizator wybiera plan wykonania, który może zwrócić tę liczbę rekordów w najszybszy możliwy sposób. Zwykle optymalizator próbuje wybrać ścieżkę, która może skutecznie zwrócić pełny zestaw wyników. Tak więc, jeśli chcesz, aby zestaw wierszy szybko wracał, możesz użyć tego, aby je odzyskać, ale w większości przypadków użycie tej wskazówki spowoduje, że cały zestaw wyników powróci wolniej, niż pozwala optymalizatorowi na użycie planu więc.

Aby rozwinąć przypadek użycia: możesz mieć dwie dość duże tabele, które musisz połączyć, ale wiesz, że istnieje tylko mniejszy zestaw danych, z którym musisz pracować z jednym z nich. W takim przypadku użycie opcji SZYBKIEJ nad większą tabelą bez konieczności tworzenia dodatkowych indeksów / kosztów ogólnych może pomóc zamiast pozwolić SQLowi utworzyć gigantyczną tabelę skrótów w tle.

Kilka lat temu natknąłem się na to samo pytanie podczas badania problemów z wydajnością w Dynamics AX. Po wyjaśnieniu Microsoftu mogłem zobaczyć inny plan wykonania uruchamiany przez podpowiedź, co odpowiada innym podanym tutaj odpowiedziom.

Dzięki podpowiedzi SQL Server próbuje znaleźć plan wykonania, który umożliwia rodzaj przesyłania strumieniowego wyników, ponieważ wychodzą one na przykład z zagnieżdżonej pętli, zamiast planu wykonania, który wymaga, aby wszystkie rekordy zostały odczytane (i potencjalnie posortowane) przed będąc wyjściem.

Jedynym problemem w moim przypadku jest to, że SQL Server zawsze zwracał (wiele) minut podczas zwracania wyników podczas korzystania z podpowiedzi, podczas gdy zapytanie zwracało wyniki (cały zestaw wyników) w ciągu kilku sekund bez podpowiedzi ... niezupełnie co był oczekiwany. Osobiście korzystam z tej wskazówki z wielką ostrożnością, a nie systematycznie we wszystkich formularzach, takich jak w naszym środowisku Dynamics (cóż, już nie).

Tak więc, aby odpowiedzieć na OP: jak wiele wskazówek, niekoniecznie pomaga ulepszyć zapytanie tak, jak powinno (więc ... testuj, testuj, testuj!)