SQL Server dispose de trois algorithmes parmi lesquels choisir lorsqu'il doit joindre deux tables. Le Nested-Loops-Join, le Hash-Join et le Sort-Merge-Join. Celui qu'il sélectionne se base sur des estimations de coûts. Dans ce cas, il a pensé que, sur la base des informations dont il disposait, un tri-fusion-jointure était le bon choix.
Dans les plans d'exécution SQL Server, un Sort-Merge est divisé en deux opérateurs, le Sort et le Merge-Join, car l'opération de tri peut ne pas être nécessaire, par exemple si les données sont déjà triées.
Pour plus d'informations sur les jointures, consultez ma série de jointures ici :http ://sqlity.net/en/1146/a-join-a-day-introduction/ L'article sur le Sort-Merg-Join est ici :http://sqlity.net/en/1480/a-join-a-day-the-sort-merge-join/
Pour rendre votre requête plus rapide, je regarderais d'abord les index. Vous avez un tas de balayages d'index clusterisés dans la requête. Si vous pouvez remplacer quelques-uns d'entre eux par des recherches, vous serez probablement mieux loti. Vérifiez également si les estimations produites par SQL Server correspondent au nombre réel de lignes dans un plan d'exécution réel. S'ils sont éloignés, SQL Server fait souvent de mauvais choix. Ainsi, fournir de meilleures statistiques peut également vous aider à interroger les performances.
