Devrais-je utiliser Query Hint Fast number_rows/FASTFIRSTROW?

Question

Je lisais sur la documentation pour obtenir des conseils de la requête: http://msdn.microsoft.com/en-us/library/ms181714(SQL.90).aspx

Et remarqué ceci: number_rows FAST Indique que la requête est optimisée pour une récupération rapide des premiers number_rows. C'est un entier non négatif. Après que les premiers number_rows sont renvoyés, la requête poursuit l'exécution et produit son jeu de résultats complet.

Alors, quand je fais une requête comme:

Select Name from Students where ID = 444 

Dois-je embêter avec un soupçon comme ça? En supposant SQL Server 2005, quand devrais-je?

- modifier -

doit une peine aussi en limitant les résultats:

Select top 10 * from Students OPTION (FAST 10) 

Answer 1

Lorsque vous utilisez TOP x, il n'y a aucun avantage de l'utilisation aussi OPTION FAST x. L'optimiseur de requête prend déjà ses décisions en fonction du nombre de lignes que vous récupérez. Il en va de même pour les requêtes triviales, telles que l'interrogation d'une valeur particulière à partir d'un index unique.

Autre que cela, OPTION FAST x pourrait aider quand vous connaissez le nombre de résultats est probablement en deçà x, mais l'optimiseur de requêtes ne fonctionne pas. Bien sûr, si l'optimiseur de requête sélectionne des chemins médiocres pour des requêtes complexes avec peu de résultats, il se peut que vos statistiques doivent être mises à jour. Et si vous devinez mal sur x, la requête peut finir par prendre plus de temps - presque toujours un risque lors de donner des conseils.

La déclaration ci-dessus n'a pas été testée - il se peut que toutes les requêtes prennent autant de temps à s'exécuter entièrement, sinon plus. Obtenir rapidement les 10 premières lignes est très bien s'il n'y a que 8 lignes, mais théoriquement, la requête doit encore s'exécuter complètement avant de finir. Le bénéfice que je pense peut être là parce que l'exécution de la requête prend un chemin différent s'attendant à moins total enregistrements, alors qu'en fait, il essaie vraiment d'obtenir le premier x plus rapidement. Ces deux types d'optimisations peuvent ne pas être alignés.

Answer 2

Pour cette requête particulière, certainement pas! Il ne va revenir qu'une ligne - la ligne avec ID = 444. SQL Server sélectionnera cette ligne aussi efficacement que possible.

FAST 10 peut être utilisé dans une situation où vous pourriez utiliser immédiatement les 10 premières lignes, même si vous continuez d'attendre d'autres résultats.

Answer 3

L'indicateur FAST n'a de sens que pour les requêtes complexes pour lesquelles l'optimiseur peut choisir parmi plusieurs alternatives. Pour une requête simple comme votre exemple, cela ne sert à rien, l'optimiseur de requêtes déterminera immédiatement qu'il existe un plan trivial (recherche dans l'index d'ID, nom de recherche s'il ne couvre pas) pour satisfaire la requête et y aller. Même si aucun index n'existe sur l'ID, le plan est toujours trivial (scan probablement clusterisé).

Pour donner un exemple où FAST serait utile, considérons une jointure entre A et B, avec une contrainte ORDER BY. Dites évaluer la boucle B de la jointure A et les boucles imbriquées A honore la contrainte ORDER BY, produira donc des résultats rapides (pas de SORT nécessaire), mais est plus coûteux en raison de la cardinalité (B a beaucoup d'enregistrements correspondant au WHERE, tandis que A en a). D'autre part, l'évaluation de la première boucle B imbriquée produirait une requête qui fait moins d'E/S, donc plus rapidement, mais le résultat devrait être trié d'abord et SORT ne peut commencer que après la jointure est évaluée, donc le premier résultat viendra très tard. L'optimiseur sélectionne normalement le deuxième plan car il est plus efficace dans l'ensemble. L'indice FAST amènerait l'optimiseur à choisir le premier plan, car il produit des résultats plus rapidement.