Cosa fa OPTION FAST nell'istruzione SELECT?

Ho fatto qualche ricerca su cosa fa il OPTION (FAST XXX)suggerimento della query all'interno di SELECTun'istruzione e sono ancora confuso su di essa. Secondo MSDN:

Specifica che la query è ottimizzata per il recupero rapido dei primi numeri. Questo è un numero intero non negativo. Dopo che vengono restituiti i primi number_rows, la query continua l'esecuzione e produce il set di risultati completo.

Per me questo non ha molto senso, ma in sostanza la query può ottenere le prime XXX righe molto velocemente rispetto alle altre a velocità normale?

La query di Microsoft Dynamics che mi ha fatto riflettere su questo è:

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

Qualcuno può spiegare esattamente cosa sta facendo questo suggerimento per la query ed è un vantaggio non usarlo?

A FAST Nindicherà a SQL Server di generare un piano di esecuzione con la restituzione rapida del numero di righe definite come N.

Si noti che le stime saranno come da Npoiché si sta dicendo al server sql di recuperare le Nrighe il più velocemente possibile.

ad es. in esecuzione sotto query con 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)

Est vs Righe effettive con option (fast 500)

Est vs Righe effettive senza option (fast 500)

Un caso d'uso sarebbe quando un'applicazione sta eseguendo la memorizzazione nella cache (carica una grande quantità di dati in background) e vuole mostrare all'utente una fetta di dati il ​​più rapidamente possibile.

Un altro caso d'uso interessante è nella terra SSIS che Rob Farley descrive usando FAST Ncome catalizzatore che accelera il recupero dei dati.

Aggiungendo questo suggerimento, sembrava che una bacchetta magica fosse stata agitata attraverso la query, per farla funzionare più volte più velocemente.

Vedi anche la risposta di Remus Rusanu .

Quando si utilizza questo suggerimento per la query OPZIONE (FAST n), l'ottimizzatore seleziona un piano di esecuzione che può restituire tale quantità di record nel modo più rapido possibile. Normalmente, l'ottimizzatore tenta di decidere un percorso che può restituire in modo efficiente il set di risultati completo. Pertanto, se si desidera che un set di righe ritorni rapidamente, è possibile utilizzarlo per recuperarle, ma nella maggior parte dei casi, l'utilizzo di questo suggerimento farà sì che il set di risultati completo ritorni più lentamente rispetto a consentire all'ottimizzatore di utilizzare un piano da eseguire così.

Solo per elaborare un caso d'uso: potresti avere due tabelle abbastanza grandi che devi unire insieme, ma sai che c'è solo un set di dati più piccolo con cui devi lavorare con uno di essi. In questo caso, l'utilizzo di FAST su una tabella più grande senza la necessità di creare indici / overhead aggiuntivi potrebbe aiutare invece di consentire a SQL di creare una tabella hash gigante in background.

Mi sono imbattuto nella stessa domanda un paio di anni fa quando ho studiato i problemi di prestazioni in Dynamics AX. Seguendo la spiegazione di Microsoft, ho potuto vedere un piano di esecuzione diverso innescato dal suggerimento e questo corrisponde alle altre risposte fornite qui.

Con il suggerimento, SQL Server tenta di trovare un piano di esecuzione che consenta una sorta di streaming di risultati, ad esempio quando escono da un ciclo nidificato, anziché da un piano di esecuzione che richiede la lettura (e l'ordinamento potenziale) di tutti i record prima in uscita.

L'unico problema nel mio caso è che il server SQL ha sempre impiegato (numerosi) minuti per restituire i risultati quando si utilizza il suggerimento, mentre la query ha restituito i risultati (l'intero set di risultati) in pochi secondi senza il suggerimento ... non del tutto era atteso. Personalmente userò questo suggerimento con grande cautela, e non sistematicamente su tutte le forme come nel nostro ambiente Dynamics (beh, non più).

Quindi, per rispondere all'OP: come molti suggerimenti, non aiuta necessariamente a migliorare la query come dovrebbe fare (quindi ... test, test, test!)