Si une instance est MAXDOPdéfinie sur 1 et que des indices de requête sont utilisés pour autoriser des requêtes spécifiques à aller en parallèle, la valeur du seuil de coût pour le parallélisme est-elle toujours utilisée par SQL pour décider si elle doit réellement aller en parallèle ou non?

Je n'ai pas été en mesure de déterrer ces informations spécifiques, bien que ce lien suggère que CTFP est ignoré si MAXDOPc'est 1. Cela a du sens sans conseils de requête car aucune demande, quel que soit le coût, ira en parallèle quand MAXDOPest 1.

Quelqu'un peut-il me faire savoir quel sera le comportement attendu de ces deux demandes?

Exemple 1:

Instance Maxdop: 1 
CTFP: 50 
Query hint: Maxdop=2 
Query cost: 30

Exemple 2:

Instance Maxdop: 1
CTFP: 50
Query hint: Maxdop=2
Query cost: 70

Si une instance est MAXDOPdéfinie sur 1 et que des indices de requête sont utilisés pour autoriser des requêtes spécifiques à aller en parallèle, la valeur du seuil de coût pour le parallélisme est-elle toujours utilisée par SQL pour décider si elle doit réellement aller en parallèle ou non?

Réponse simple: oui .

Détails

Il y a quelques choses distinctes qui se passent ici, qu'il est important de séparer:

1. Quel est le degré de parallélisme maximal effectif disponible pour une requête?

   Les contributeurs à cela sont (globalement par ordre d'importance):

   • MAX_DOPRéglage du gouverneur de ressources
   • Soupçon requête MAXDOPparamètre
   • L' max degree of parallelismoption de configuration d'instance

   Les détails sont expliqués dans le paramètre «Degré maximal de parallélisme» du serveur, MAX_DOP du gouverneur de ressources et l'indicateur de requête MAXDOP - lequel SQL Server doit-il utiliser? par Jack Li, ingénieur principal en escalade pour le service client et le support Microsoft SQL Server. Le tableau ci-dessous est reproduit à partir de ce lien:

   

2. Un plan de requête utilisera-t-il le parallélisme?

   L'optimiseur de requêtes SQL Server recherche toujours d'abord un plan série *.

   Puis si:

   • Une optimisation plus poussée est justifiée; et
   • Le coût du meilleur plan série dépasse la cost threshold for parallelismvaleur de configuration

   
   ... l'optimiseur va essayer de trouver un plan parallèle.

   Puis si:

   • Un plan parallèle est trouvé (c'est à dire possible); et
   • Le coût du plan parallèle est inférieur au meilleur plan série

   
   ... un plan parallèle sera produit.

Remarque: la cost threshold for parallelismseule influence si l'optimiseur recherche un plan parallèle. Une fois qu'un plan parallèle est mis en cache, il s'exécute en utilisant le parallélisme lorsqu'il est réutilisé (tant que les threads sont disponibles) quel que soit le paramètre CTFP.

Exemples

Pour les deux exemples, avec l'instance maxdop 1 et l'indicateur de requête maxdop 2, le DOP disponible effectif est 2. Si un plan parallèle est choisi, il utilisera DOP 2.

Exemple 1

Étant donné le CTFP de 50 et le coût de base d'un plan série le moins cher de 30, SQL Server n'essaiera pas de trouver un plan parallèle. Un plan de série sera produit.

Exemple 2

Étant donné le CTFP de 50 et le coût de base d'un plan série le moins cher de 70, SQL Server essaiera de trouver un plan parallèle. Si ce plan (s'il est trouvé) a un coût inférieur à 70 (le coût du plan de série), un plan parallèle sera produit.

_{Le résultat final de l'optimisation des requêtes est toujours un plan en cache unique: série ou parallèle. L'optimiseur ne trouve qu'un plan série dans les phases search0 (TP) et search1 (QP).}

_{Il peut ensuite (comme décrit) réexécuter search1 avec la nécessité de produire un plan parallèle. Un choix est alors fait entre série et parallèle sur la base du meilleur coût du plan jusqu'à présent. Ce choix est contraignant au cas où l'optimisation passe à la recherche2 (optimisation complète). Chaque phase d'optimisation considère de nombreuses alternatives, mais la sortie d'une étape est toujours un plan unique optimal, qui est soit en série soit en parallèle.}

_{J'ai écrit à ce sujet dans Mythe: SQL Server met en cache un plan série avec chaque plan parallèle}

Exemple 1 Instance Maxdop: 1 CTFP: 50 Indice de requête: Maxdop = 2 Coût de la requête: 30

L'indicateur de requête MAXDOP remplace le degré maximal de parallélisme définissant l'instance à l'échelle, mais comme le CTPF est de 50 et le coût de la requête est de 30, il peut aller pour le plan série.

Exemple 2 Instance Maxdop: 1 CTFP: 50 Indice de requête: Maxdop = 2 Coût de la requête: 70

Ici encore, le degré maximum de parallélisme sera pris comme 2 puisque l'indication MAXDOP est là mais CTFP sera pris comme 50 et la requête, si possible comme Paul l'a mentionné, peut fonctionner en parallèle.

Si MAXDOP est défini sur 1 dans une instance et que des indices de requête sont utilisés pour permettre à des requêtes spécifiques de se dérouler en parallèle, la valeur du seuil de coût pour le parallélisme est-elle toujours utilisée par SQL pour décider si elle doit ou non être parallèle?

L'indication MAXDOP remplacera le paramètre à l'échelle de l'instance du degré maximal de parallélisme.

Citation de l'indication MAXDOP docs.microsoft

Numéro MAXDOP S'applique à: SQL Server 2008 à SQL Server 2017.

Substitue l'option de configuration du degré maximal de parallélisme de sp_configure et du gouverneur de ressources pour la requête spécifiant cette option. L'indicateur de requête MAXDOP peut dépasser la valeur configurée avec sp_configure. Si MAXDOP dépasse la valeur configurée avec le gouverneur de ressources, le moteur de base de données utilise la valeur MAXDOP du gouverneur de ressources,