Il est toujours recommandé lors de l'écriture de requêtes ou de code de base de données SQL Server (procédures et vues) de prendre connaissance du plan d'exécution. Il y a plusieurs raisons à cela. Premièrement, l'optimiseur peut choisir un plan auquel vous ne vous attendez pas. Par exemple, indexez le balayage d'une grande table avant de faire correspondre avec une table plus petite. Deuxièmement, il convient de tenir compte de la manière dont cette requête fonctionnera dans les mois ou les années à venir si les requêtes s'exécutent dans un nouveau système avec de petites tables qui vont croître. Et enfin, mais surtout, à quelle vitesse est cette requête et combien de ressources utilise-t-elle. Le dernier point peut ne pas sembler si important, vous pensez peut-être que tant que cela prend moins de 3 secondes, c'est assez bien, mais si cela pouvait fonctionner en moins de 1 seconde, cela ne serait-il pas mieux ? Si vos bases de données sont hébergées dans le cloud, la réduction des ressources peut également vous faire économiser de l'argent.
De nombreux cas d'optimisation SQL proviennent normalement d'un problème détecté par l'utilisateur final ou votre logiciel de surveillance. « Pourquoi ce rapport prend-il 30 minutes à générer ? », « Qu'est-ce qui cause ce pic d'attente d'E/S » ou « Pourquoi ces tâches prennent-elles deux fois plus de temps à s'exécuter que l'année dernière ? »
Dans tous ces scénarios, il s'agit toujours d'une certaine connaissance des plans d'exécution et de la meilleure façon de corriger le SQL pour améliorer la situation, ce qui peut prendre beaucoup de temps et ne pas toujours réussir.
Prenons un exemple. Donc, vous écrivez une nouvelle requête, l'exécutez, puis pensez, oh mon Dieu, cela prend trop de temps.
17 secondes pour 730 lignes, que dois-je faire ?
Examinons d'abord le plan d'exécution :
Ce n'est pas toujours simple si vous devez zoomer et dézoomer pour le comprendre. Donc, le premier conseil est d'obtenir une bonne visionneuse de plan comme celle-ci avec le Spotlight Tuning Pack.
La visionneuse de plan met en évidence les éléments d'information clés dont nous avons besoin et où se trouvent les principales opérations, ainsi que les avertissements.
Voici un exemple :
Donc, il y a un problème avec ce code, mais que pouvons-nous faire ?
Eh bien, en fait beaucoup. Nous pourrions utiliser des conseils de requête, envisager d'ajouter des index (n'oubliez pas que cela pourrait avoir un impact sur d'autres requêtes et DML), ajouter des morceaux de code qui ne modifient pas le jeu de résultats mais influencent l'optimiseur pour générer un plan différent et de petites astuces pour arrêter l'optimiseur en considérant un index particulier qu'il utilise et peut-être générer un nouveau plan. Mais tout cela n'est qu'essais et erreurs et prend beaucoup de temps à faire manuellement.
En ajoutant l'application Spotlight Extensions à SSMS et en vous abonnant au Spotlight Tuning Pack, nous pouvons laisser la fonction d'optimisation du Tuning Pack faire tout le travail à notre place.
Vous avez peut-être remarqué dans la première capture d'écran que lorsque la fonctionnalité est activée, elle détecte automatiquement qu'une optimisation est possible :
Cliquez sur Afficher l'analyse
Vous pouvez ensuite cliquer sur le bouton Optimiser et le moteur d'optimisation analysera le code et commencera à appliquer des règles de réécriture qui modifieront la syntaxe du SQL donnant des alternatives qui fournissent le même ensemble de résultats, puis les tester afin que nous puissions voir si une exécution alternative les plans sont plus rapides et pourquoi. Les règles sont appliquées en combinaisons, de sorte que les alternatives possibles peuvent être supérieures à 100. Cependant, l'outil ne vous montre que des alternatives plus rapides que l'original.
Ce processus s'exécute en arrière-plan et vous fait gagner un temps considérable si vous tentiez de le faire manuellement.
Et lorsque les résultats sont affichés, vous pouvez comparer les alternatives, voir les différences de code, comparer les plans et consulter les statistiques.
Donc, revenons à SSMS avec ma nouvelle version de la requête et testez-la.
Succès.
S'il s'agit d'un environnement de développement, vous pouvez envisager de vider le cache de tampon à l'aide de DBCC DROPCLEANBUFFERS pour tester vos requêtes avec un cache de tampon à froid sans arrêter ni redémarrer le serveur.
Envisagez également d'ajouter SET STATISTICS IO ON à la requête pour plus d'informations sur les raisons pour lesquelles la syntaxe de la requête a fait une différence :
Original :
Réécrire :
Et cela peut également être réalisé dans le Tuning Pack avec la fonction de comparaison des statistiques :
Donc, avec le changement réussi et l'utilisateur final heureux, passons à la requête suivante. En améliorant continuellement les performances des requêtes individuelles, nous améliorons les performances de l'instance.
