Réglage des performances des requêtes

Lorsque vous avez terminé d'écrire une requête / proc / fonction stockée, quelle est la manière la plus informative d'obtenir rapidement certains paramètres de performances? Exécutez-vous la requête et affichez le plan d'exécution réel? Si oui, quelles sont les choses que vous recherchez? De toute évidence, les analyses de table / d'index sont les hits de bits, mais quoi d'autre?

Pour une évaluation rapide, extrayez le plan d'exécution de SSMS et accédez à Plan Explorer .

• Passez en revue les opérations les plus coûteuses pour tout imprévu. Trie, tables de travail, opérateurs de jointure inappropriés (par exemple, boucle imbriquée où vous attendez une fusion ou un hachage).
• Regardez les décomptes à chaque étape du plan, sont-ils globalement dans la plage que vous attendiez?
• Regardez les lignes estimées et réelles. Si vos chiffres réels sont proches des estimations, il est plus probable que vous ayez un bon plan. S'il existe de grandes variations, découvrez pourquoi (statistiques manquantes et / ou obsolètes par exemple).
• Évaluer le potentiel de problèmes de reniflage de paramètres. Recherchez les zones où la cardinalité peut varier et testez en fonction d'une gamme de paramètres d'entrée.

Beaucoup de documents de référence disponibles gratuitement, les plans d'exécution SQL Server de Grant Fitchley sont un bon début. J'ai également trouvé les articles de blog et l'ebook sur le plan d'exécution de Joe Chang très utiles.

Généralement, tout ce que je fais, c'est simplement exécuter la requête et découvrir comment elle s'exécute par rapport aux données réelles. S'il y a un problème, je regarde les plans d'exécution.

Quant aux plans d'exécution, Brad McGehee a un article intéressant sur le sujet.

Il y dit:

Si vous voyez l'un des éléments suivants dans un plan d'exécution, vous devez les considérer comme des signes d'avertissement et rechercher les problèmes de performances potentiels. Chacun d'eux n'est pas idéal du point de vue des performances.

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

Il n'est pas toujours possible de les éviter, mais plus vous pourrez les éviter, plus les performances des requêtes seront rapides.

SET STATISTICS IO ON

En règle générale, le "nombre de lectures logiques" doit être aussi faible que possible. Les quelques pages touchées pour terminer la requête, meilleur est le plan car il sera (généralement) plus rapide, moins d'impact sur le CPU, la RAM et les E / S du disque.

Cela vous guidera lorsque la modification des index ou la refactorisation du SQL est réellement utile. L'examen du «temps d'exécution en millisecondes» variera même avec le même plan SQL et de requête - les lectures logiques resteront cohérentes pour tout plan de requête donné.

Les "lectures physiques" doivent également être très faibles (et être nulles et rester nulles pour les exécutions ultérieures). Si cela ne fonctionne pas, examinez votre utilisation de la mémoire SQL Server (durée de vie de la page, etc.).