J'ai une requête contenant trois relevés de jointure intérieure dans la clause WHERE. La requête prend environ 2 minutes pour exécuter. Si je modifie simplement l'ordre de deux des jointures intérieures, les performances tombent à 40 secondes.
Comment ne peut rien faire mais changer l'ordre des jointures intérieures a un impact aussi drastique de la performance de la requête? J'aurais pensé que l'optimiseur trouverait tout cela.
3 Réponses :
Par exemple, en modifiant l'ordre des jointures, SQL Server propose un plan d'exécution différent pour votre requête (il y a des chances que cela change de manière à filtrer les tables en fonction de vos joints).
Dans ce cas, je suppose que vous avez plusieurs grandes tables ... dont l'une exécute la majorité du filtrage.
Dans une requête, vos jointures joignent plusieurs des grandes tables ensemble, puis filtrant les enregistrements à la fin.
Dans l'autre, vous filtrez la première table à un sous-ensemble beaucoup plus petit des données ... puis rejoignez le reste des tables dans. Depuis que cette table initiale a été filtrée avant de rejoindre les autres grandes races, la performance est bien meilleure.
Vous pouvez toujours vérifier mais exécuter la requête avec l'option "Afficher le plan de requête" activée et voir ce que le plan de requête est pour les deux commandes de jointure différentes.
J'aurais pensé que c'était assez intelligent de le faire également, mais il est clairement exécutant les jointures dans l'ordre que vous les énumérer explicitement ... pourquoi cela affecte les performances, si la première jointure produit un résultat intermédiaire Ensemble de seulement 100 enregistrements dans un schéma de commande, le second joint sera à partir de cet ensemble de 100 enregistrements sur la troisième table. Si la mise en place de l'autre JOOK produise d'abord un premier ensemble de résultats intermédiaire d'un million d'enregistrements, la seconde jointure passera d'un million de résultats défini sur la troisième table ...
Le plan de requête modifiera généralement une rétrocaction de manière optimale, mais il reçoit un délai d'attente dans lequel elle peut optimiser une requête. Si la requête est très compliquée, cela abandonnera et utilisera le meilleur plan que cela a été trouvé jusqu'à présent. Si vous cliquez sur "Afficher le plan d'exécution XML", vous verrez ceci comme relevéoptmearlyaborTrason = "timeout"
SQL est déclaratif, c'est-à-dire que la commande de jointure ne devrait pas avoir d'importance.
Cependant, il peut en pratique, disons, s'il s'agit d'une requête complexe lorsque l'optimiseur n'explore pas toutes les options (ce qui pourrait prendre des mois).
Une autre option est que c'est une requête très différente si vous réorganisez et vous obtenez des résultats différents, mais cela est généralement avec des jointures extérieures.
Et cela pourrait aussi être la manière dont la clause ON est spécifiée, il doit changer si vous réorganisez la clause de la clause. Sauf si vous utilisez l'ancienne (et la mauvaise) jointure dans la clause.
Enfin, si c'est une préoccupation, vous pouvez utiliser des parenthèses pour modifier l'ordre d'évaluation pour que vos intentions soient claires, disons, filtrez d'abord sur une grande table pour générer une table dérivée.
Cela ne devrait normalement pas. ID Vous testez-le à la fois plus d'une fois? Pouvez-vous poster les deux versions?