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?

sql-server performance query

Réponses:

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.

— Mark Storey-Smith
source

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.

— Richard
source

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.).

— Gars
source

Mais pour les requêtes qui sont exécutées lorsqu'il n'y a pas dans le cache de requêtes, les lectures physiques seront supérieures à zéro, non? Je veux dire, vous ne pouvez pas toujours contourner cela, car toutes les requêtes (en particulier les requêtes ad hoc) ne sont pas mises en cache. Ai-je raison?

— Thomas Stringer

@ Surfer513 pour prendre en charge la mise en cache des données, vous pouvez émettre un CHECKPOINT suivi d'un DBCC DROPCLEANBUFFERS pour effacer le pool de tampons (cache de données). Notez que cela effacera les tampons pour tout le monde, alors utilisez-le en conséquence (sur les systèmes de test).

— StanleyJohns

@StanleyJohns, pourquoi voudriez-vous vider le cache de données / requêtes?

— Thomas Stringer

De cette façon, les E / S physiques seront les mêmes à chaque fois, donnant la cohérence requise pour les tests. Cela vous aidera à affiner la requête.

— StanleyJohns

J'ignorerais les statistiques d'E / S physiques car elles sont sous le contrôle de l'infrastructure sous-jacente et intégreront la mise en mémoire tampon SAN et OS. Les E / S logiques sont une mesure de la quantité de TRAVAIL que l'instruction SQL a dû faire. Si le SQL fait moins d'E / S logique, alors il fait moins de travail.

— Guy