Dans quelle mesure la création d'un plan d'exécution est-elle déterministe dans SQL Server?

Étant donné les constantes suivantes:

La même base de données avec la même structure (tables, index, etc.)
Les mêmes données
La même configuration de SQL Server et du matériel
Les mêmes statistiques
Les mêmes options SET dans le client
Les mêmes versions de SQL Server
Les mêmes indicateurs de trace

Compte tenu de ces constantes, SQL Server produira-t-il toujours le même plan pour une requête donnée?

Sinon, y a-t-il d'autres considérations? Y a-t-il également un élément de non-déterminisme à prendre en compte?

sql-server execution-plan determinism

— James L
source

il sera incorrect de dire le même plan, mais nous pouvons dire un plan similaire. Avec les facteurs externes que DBA / Developer peut contrôler; Les «algorithmes d'optimisation du plan de requête» et les «algorithmes de coût des requêtes internes» sont écrits dans le moteur de serveur SQL. nous n'avons pas le contrôle de dire «quoi choisir» de toutes les manières. nous pouvons définir env externe pour guider le moteur à choisir le mieux. pour une requête donnée, si l'optimiseur a mis au point deux plans d'exécution avec une différence de coût de 0,001, je suppose que le plan d'exécution qu'il choisira ne sera pas pertinent.

— Anup Shah

Je ne pense pas que vous devriez être trop théorique à ce sujet. J'ai travaillé 25 ans avec différentes bases de données et il est presque toujours possible de réécrire une requête pour mieux l'exécuter. Et parfois, il est très difficile de comprendre pourquoi c'est mieux avec une façon d'écrire la requête.

Compte tenu de ces constantes, SQL Server produira-t-il toujours le même plan pour une requête donnée? Sinon, y a-t-il d'autres considérations? Y a-t-il également un élément de non-déterminisme à prendre en compte?

La compilation des requêtes est déterministe pour autant que je sache. L'un des objectifs de conception d'origine de QO était qu'il devrait être possible de reproduire les plans d'exécution sur un système différent en utilisant une copie uniquement statistique de la base de données. Il y a quelques subtilités à cela, autour des paramètres de configuration comme la quantité de mémoire disponible et le nombre de processeurs logiques, mais ceux-ci sont couverts par votre liste de choses à synchroniser.

Mise en garde: Cela est vrai à condition que le mot «même» dans votre liste soit considéré comme signifiant exactement le même à tous égards . Par exemple, les «mêmes» statistiques peuvent exister sur les deux systèmes, mais elles ne sont exactement les mêmes que si les étapes de l'histogramme et les informations de densité sont identiques .

Cela dit, le processus d'optimisation est également extrêmement complexe , ce qui signifie qu'il peut être difficile de garantir que toutes les entrées de ce processus déterministe sont identiques et que tous les états internes sont suffisamment similaires pour garantir que le même chemin de code est emprunté par l'optimiseur pour un particulier. compilation. Si la requête contient un accès en dehors de la base de données (vers une autre base de données ou instance), ces environnements doivent également être identiques.

Une chose que j'ajouterais à votre liste est de vérifier que tous les guides de plan existent également dans la deuxième base de données.

L'utilisation de fonctions non déterministes comme GETDATE()dans les requêtes peut également signifier que vous obtenez un plan différent. Bien que l'optimiseur principal n'utilise pas directement la valeur, l'estimation de cardinalité peut (voir Évaluation du pliage constant et de l'expression pendant l'estimation de cardinalité ). Je ne sais pas si cette classe de différence entre dans le champ d'application de la question, car les deux systèmes produiraient le même plan s'ils étaient exécutés en même temps (ou, plus généralement, avec les mêmes variables d'entrée, paramètres et valeurs de fonction).

— Paul White 9
source