plans d'exécution pour les bases de données

Question

Question 1:

Lorsque nous exécutons une requête, que la modification de plan d'exécution pour chaque fois lors de l'exécution de la requête?

Si oui, quel type de performance est atteint? Si non, alors si nous changeons quelque chose dans la table, c'est-à-dire en ajoutant un index, comment la base de données sait-elle qu'il y a quelque chose qu'elle peut utiliser pour changer le plan d'exécution pour une exécution plus rapide?

Question 2:

Mais quel est l'ordre général d'exécution lors de l'exécution d'une requête de jointure, surtout s'il y a beaucoup de jointures (extérieur, intérieur, naturel, si beaucoup extérieur).

Answer 1

• Pour être exact pour SQL Server:

Vous avez dans la plupart des deux plans dans le cache (un parallèle, un non-parallèles). Ensuite, le plan est utilisé avec un Contexte d'exécution par utilisateur.More info in my answer here

• ordre de jointure est hors de propos dans presque tous les cas

SQL est déclarative. Cela signifie que vous dites au moteur ce que vous voulez et que l'optimiseur élabore le meilleur plan (dans la mesure du possible, cela peut prendre deux semaines pour trouver le meilleur). C'est pourquoi vous pouvez réécrire des requêtes de différentes manières pour obtenir la même réponse.

Comme toutes les règles concernant le SGBDR, il existe des exceptions. Pour les requêtes complexes, l'optimiseur ne passera pas par toutes les permutations, donc l'ordre JOIN peut avoir de l'importance: cela dépend quand l'optimiseur décide qu'il en a assez ...

Answer 2

(En supposant SQL Server ici, vous ne l'avez pas spécifié ...)

plans d'exécution sont mises en cache, et dans la mesure que vous paramétrez vos requêtes, peuvent être réutilisés. Lorsque vous modifiez la ou les tables sous-jacentes, SQL Server connaît la date de modification de ces éléments par rapport au plan d'exécution mis en cache et peut réévaluer la requête pour les nouvelles conditions. Même chose lorsque les statistiques sont mises à jour ... parfois, les données propulsent le plan, pas seulement la conception de la table/de l'index.

Answer 3

Les jointures ne sont pas effectuées dans un ordre basé sur l'interne et l'externe, mais plutôt sur ce que l'optimiseur pense que la requête sera exécutée le plus rapidement. Les détails varieront entre les bases de données. Mais fondamentalement, l'optimiseur de requête essaie d'optimiser l'utilisation des index.

Supposons que vous ayez cette requête:

select a.foo, b.bar 
from a 
join b on b.b_id=a.b_id 
where a.some_number=42; 

Supposons maintenant que vous avez un index unique sur b.b_id mais pas d'index sur a.some_number. L'optimiseur de requête a alors deux choix: Il peut effectuer une lecture séquentielle complète de fichiers sur b, puis, pour chaque b, effectuer une lecture séquentielle de fichiers complets en recherchant une correspondance sur b_id et some_number = 42. C'est lire les enregistrements a^b. Ou il pourrait faire une lecture séquentielle de fichiers complets en recherchant some_number = 42, puis pour chaque a, il pourrait utiliser l'index pour trouver rapidement l'enregistrement de b avec b_id correspondant. C'est, lire un * 2 enregistrements. Bien évidemment le deuxième plan est bien meilleur, alors c'est ce qu'il va choisir. Lorsque vous ajoutez d'autres tables, le calcul devient plus compliqué, mais le principe est le même. Les jointures qui aboutissent à une lecture rapide de l'index à l'aide des valeurs trouvées dans d'autres tables seront effectuées plus tard, une fois les autres tables lues. Les tables qui doivent être lues de manière séquentielle, peu importe quoi, ou où la lecture est basée sur des constantes plutôt que sur des valeurs provenant d'autres enregistrements, sont généralement lues en premier.