SQL Server Training - Estimated Execution plan

L'affichage du plan d'exécution est possible de différentes façon (entre autre via l'interface du SQL Analyser ou via SET STATISTICS XML ON).
Un précédent article sur les stored procedure traitait de cet activation.
Celui ci, plus pragmatique, fournira quelqyes de détails utiles pour la lecture du plan d'exécution.

Les flux d'informations
Les flux d'informations sont symbolisés par des flèches plus ou moins épaisses.
Plus elles sont épaisses, plus le flux d'information est gros (en terme de milliers de records).
Il va de soi que les flux d'informations en amont du plan d'exécution (les sélections de données depuis la DB) doivent être aussi restreints que possible.
Plus ils seront importants et plus le coût s'en ressentira sur le temps de traitement (jointure, tri, filtrage) et la consommation de la mémoire de travail.

Les jointures
En interne, l'engine SQL utilise plusieurs algorithmes pour joindre des rowset de source différentes.
Parmis ces algorithmes, il y a:

1. Le Merge Join.
2. Le Hash Join.
3. Le Nested Loop Join
   

Le Merge Join
Le merge join est l'opération la moins couteuse et la plus rapide.
Les deux rowsets peuvent être joints en une seule opération continue.
Cette opération n'est possible que si les deux rowset sont stockés (produit) avec le même tri.

Le Hash Join
Opération plus couteuse que le merge join et donc plus lente. Dans ce cas de figure, une clé de hashage doit être produite sur les données avant une opération de Merge Join.
Cet opération nécessite l'usage d'une "table temporaire" pour stocker les résultats intermédiaires, elle est donc gourmande en mémoire.

Le Nested Loop Join
L'opération Nested Loop est sans conteste l'opération la plus couteuse (et de loin). 
Pour chaque entrée d'un rowset, SQL Serveur effectue une opération de recherche dans le second. Le Nested Loop Join a donc des performances catastrophiques.
Cette jointure n'est envisagée par SQL server qu'en dernier recours.
Une façon de l'éviter est, en autre, de donner un maximum d'informations au "query optimizer".
Cela est possible:

1. En complétant au maximum la requête SQL (plus de critères dans la clause WHERE, augmenter les critères de jointures dans les joints, etc).
2. Réécrire la requête SQL différement (par exemple, remplacer les outer join par des sub-query).