Existe-t-il un moyen d'empêcher la taille de la structure des mémos?

8

Nous savons que la structure des mémos est élaguée et que certains plans alternatifs coûteux sont ignorés lors de l'optimisation. Je me demandais s'il y avait un moyen d'empêcher cela et de laisser l'optimiseur considérer simplement tous les plans possibles et sélectionner le meilleur parmi toutes les alternatives?

sql-server optimization

— zli89
source

3

Ce que vous voulez empêcher n'est pas clair. Voulez-vous en quelque sorte forcer l'optimiseur à calculer un coût pour tous les plans possibles (qui peuvent être sur des milliards de milliards, même pour une requête simple avec 10 jointures)?

— ypercubeᵀᴹ

oui, bien que cela ne semble pas possible. Je voudrais forcer l'optimiseur à considérer tous les plans possibles, à calculer leurs coûts, puis à choisir le moins cher.

— zli89

4

Et pourquoi devrait-il faire ça? S'il a calculé, disons, un plan avec un coût = 7, puis constate que tout plan qui inclut a hash join bcoûtera 10 ou plus, pourquoi calculer tous ces millions de plans et ne pas les tailler? (pas que l'optimiseur fonctionne de manière aussi simpliste)

— ypercubeᵀᴹ

12

Nous savons que la structure des mémos est élaguée et que certains plans alternatifs coûteux sont ignorés lors de l'optimisation. Je me demandais s'il y avait un moyen d'empêcher cela et de laisser l'optimiseur considérer simplement tous les plans possibles et sélectionner le meilleur parmi toutes les alternatives?

Il y en a un, mais je ne le publie pas car il serait mal compris et mal appliqué. Dans tous les cas, cela n'aboutirait pas à une recherche exhaustive de l'espace du plan car seul un ensemble limité de transformations (celles qui produisent généralement de bons résultats) sont mises en œuvre.

La prévention de l'élagage et de la suppression se traduirait généralement par des temps de compilation (beaucoup) plus longs sans beaucoup d'amélioration de la qualité du plan final, le cas échéant.

En fin de compte, la question est naturelle et raisonnable, mais elle repose sur une mauvaise compréhension des objectifs de l'optimiseur de requêtes SQL Server: il est conçu pour trouver rapidement de bons plans pour les requêtes courantes. Il n'est pas construit sur un cadre conçu pour une recherche exhaustive.

Si vous avez une situation réelle qui bénéficierait d'une approche différente de l'optimisation, vous pouvez le faire valoir sur le site Web Connect (bien que je pense qu'il est peu probable que Microsoft investisse les ressources d'ingénierie nécessaires).

— Paul White 9
source

9

Je ne connais aucun bouton ou indicateur de trace pour contraindre ce comportement de quelque manière que ce soit (bien que Paul White mentionne ici quelques indicateurs de trace qui offrent plus de visibilité et vous permettent d'amadouer certains deltas de comportement ).

Microsoft fournit de nombreuses armes, mais celle-ci serait presque garantie de pointer carrément vers vos pieds 100% du temps. Lorsque vous exécutez une requête pour la première fois, je ne pense pas que vous souhaitiez que SQL Server passe une quantité infinie de temps à construire chaque variante possible d'un plan pour obtenir les résultats souhaités. Comme @ypercube le mentionne, cela pourrait être un très grand nombre de plans, et cela pourrait en quelque sorte contrecarrer l'objectif de l'exécution de la requête. Votre objectif en exécutant une requête en premier lieu, probablement, est de renvoyer des données à un moment donné, non? Et "un certain point" doit se situer dans certains seuils, car certaines couches de votre application auront différents délais d'expiration de requête / commande, et les utilisateurs n'attendront que si longtemps qu'une page se charge ...

— Aaron Bertrand
source