Analyser les requêtes

Comment analyser les requêtes pour identifier les problèmes de performances. Marche à suivre.

Voici une checklist résumée de la méthodologie pour analyser les performances d’une requête ou d’une base de données SQL Server.

1. Regarder les IO -> SET STATISTICS IO ON

Si beaucoup d’IO sur une table, est-ce qu’on a un index ? (https://youtu.be/BqmaDUumoxk)

SET STATISTICS IO, TIME ON (https://youtu.be/wThNVZciebQ)
Différence entre temps CPU et temps total
CPU < temps total => attentes – pas de la faute de la requête – par exemple blocages de verrous, lectures sur le disque, comportement du datareader (https://youtu.be/AbmUxVNF-Pc)
CPU > temps total => parallélisme (https://youtu.be/pqaZPhpXt1w) – pas grave

Y a-t-il une différence d’estimation de cardinalité ? C’est grave quand il estime trop peu.
Utiliser de préférence Plan Explorer – https://www.sentryone.com/plan-explorer
Si différence – recalculer les statistiques (https://youtu.be/a-0JJNXdVsw, https://youtu.be/FEZSpL36O_w pour le recalcul dans le plan de maintenance)
Ça pourrait être une variable de type table : si oui OPTION (RECOMPILE) ou SQL Server 2017.
Ça peut être le moteur d’estimation (CE).
- Si erreur d’estimation de cardinalité sur une requête complexe, essayer de jouer avec la version du CE.
- OPTION (USE HINT('FORCE_LEGACY_CARDINALITY_ESTIMATION'))
- OPTION (USE HINT('ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'))
- OPTION (USE HINT('FORCE_DEFAULT_CARDINALITY_ESTIMATION'))
- ALTER DATABASE SCOPED CONFIGURATION SET LEGACY_CARDINALITY_ESTIMATION = On;

Utiliser les évènements étendus en filtrant sur la durée
Utiliser les évènements étendus sans filtre un petit moment pour voir s’il y a des requêtes répétitives ou doublonnées.
Regarder les statistiques de requête : https://github.com/rudi-bruchez/tsql-scripts/blob/master/diagnostics/execution-stats/dm_exec_query_stats.sql