Indicateurs (Transact-SQL) - Requête
S’applique à :
SQL ServerAzure SQL DatabaseAzure SQL Managed Instance
Les indicateurs de requête spécifient que les indicateurs mentionnés sont utilisés dans l’étendue d’une requête. Ils s’appliquent à tous les opérateurs de l’instruction. Si une clause UNION se trouve dans la requête principale, seule la dernière requête impliquant une opération UNION peut avoir la clause OPTION. Les indicateurs de requête sont spécifiés dans la clause OPTION. L’erreur 8622 se produit si un ou plusieurs indicateurs de requête empêchent l’optimiseur de requête de générer un plan valide.
Attention
Comme l’optimiseur de requête SQL Server sélectionne généralement le meilleur plan d’exécution pour une requête, nous recommandons de ne recourir aux indicateurs qu’en dernier ressort, et à condition d’être un développeur ou un administrateur de base de données expérimenté.
S’applique à :
Conventions de la syntaxe Transact-SQL
Syntaxe
<query_hint> ::=
{ { HASH | ORDER } GROUP
| { CONCAT | HASH | MERGE } UNION
| { LOOP | MERGE | HASH } JOIN
| DISABLE_OPTIMIZED_PLAN_FORCING
| EXPAND VIEWS
| FAST <integer_value>
| FORCE ORDER
| { FORCE | DISABLE } EXTERNALPUSHDOWN
| { FORCE | DISABLE } SCALEOUTEXECUTION
| IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX
| KEEP PLAN
| KEEPFIXED PLAN
| MAX_GRANT_PERCENT = <numeric_value>
| MIN_GRANT_PERCENT = <numeric_value>
| MAXDOP <integer_value>
| MAXRECURSION <integer_value>
| NO_PERFORMANCE_SPOOL
| OPTIMIZE FOR ( @variable_name { UNKNOWN | = <literal_constant> } [ , ...n ] )
| OPTIMIZE FOR UNKNOWN
| PARAMETERIZATION { SIMPLE | FORCED }
| QUERYTRACEON <integer_value>
| RECOMPILE
| ROBUST PLAN
| USE HINT ( <use_hint_name> [ , ...n ] )
| USE PLAN N'<xml_plan>'
| TABLE HINT ( <exposed_object_name> [ , <table_hint> [ [ , ] ...n ] ] )
}
<table_hint> ::=
{ NOEXPAND [ , INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> ) ]
| INDEX ( <index_value> [ , ...n ] ) | INDEX = ( <index_value> )
| FORCESEEK [ ( <index_value> ( <index_column_name> [ , ... ] ) ) ]
| FORCESCAN
| HOLDLOCK
| NOLOCK
| NOWAIT
| PAGLOCK
| READCOMMITTED
| READCOMMITTEDLOCK
| READPAST
| READUNCOMMITTED
| REPEATABLEREAD
| ROWLOCK
| SERIALIZABLE
| SNAPSHOT
| SPATIAL_WINDOW_MAX_CELLS = <integer_value>
| TABLOCK
| TABLOCKX
| UPDLOCK
| XLOCK
}
<use_hint_name> ::=
{ 'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'
| 'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES'
| 'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES'
| 'ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES'
| 'DISABLE_BATCH_MODE_ADAPTIVE_JOINS'
| 'DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK'
| 'DISABLE_DEFERRED_COMPILATION_TV'
| 'DISABLE_INTERLEAVED_EXECUTION_TVF'
| 'DISABLE_OPTIMIZED_NESTED_LOOP'
| 'DISABLE_OPTIMIZER_ROWGOAL'
| 'DISABLE_PARAMETER_SNIFFING'
| 'DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK'
| 'DISABLE_TSQL_SCALAR_UDF_INLINING'
| 'DISALLOW_BATCH_MODE'
| 'ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS'
| 'ENABLE_QUERY_OPTIMIZER_HOTFIXES'
| 'FORCE_DEFAULT_CARDINALITY_ESTIMATION'
| 'FORCE_LEGACY_CARDINALITY_ESTIMATION'
| 'QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n'
| 'QUERY_PLAN_PROFILE'
}
Remarque
Pour afficher la syntaxe Transact-SQL pour SQL Server 2014 (12.x) et versions antérieures, consultez la Documentation sur les versions antérieures.
Arguments
{ HASH | ORDER } GROUP
Indique que les agrégations décrites par la clause GROUP BY ou DISTINCT de la requête doivent utiliser le hachage ou le tri.
{ MERGE | HASH | CONCAT } UNION
Indique que toutes les opérations UNION doivent être exécutées par fusion, hachage ou concaténation d'ensembles UNION. Si plusieurs indicateurs UNION sont spécifiés, l’optimiseur de requête sélectionne la stratégie la moins coûteuse parmi les indicateurs spécifiés.
{ LOOP | MERGE | HASH } JOIN
Indique que toutes les opérations de jointure doivent être effectuées par LOOP JOIN, MERGE JOIN ou HASH JOIN dans toute la requête. Si plusieurs indicateurs de jointure sont spécifiés, l'optimiseur sélectionne la stratégie la moins coûteuse parmi celles qui sont autorisées.
Si vous spécifiez un indicateur de jointure dans la clause FROM de la même requête pour une paire de tables spécifique, il est prioritaire dans la jointure des deux tables. Les indicateurs de requête, toutefois, doivent quand même être respectés. L’indicateur de jointure pour la paire de tables peut limiter uniquement la sélection des méthodes de jointure autorisées dans l’indicateur de requête. Pour plus d’informations, consultez Indicateurs de jointure (Transact-SQL).
DISABLE_OPTIMIZED_PLAN_FORCING
S’applique à : SQL Server (à compter de SQL Server 2022 (16.x))
Désactive le forçage de plan optimisé pour une requête.
Le forçage de plan optimisé réduit la surcharge de compilation pour les requêtes forcées répétées. Une fois le plan d’exécution de requêtes généré, des étapes de compilation spécifiques sont stockées pour être réutilisées en tant que script de relecture d’optimisation. Un script de relecture d’optimisation est stocké dans le cadre du XML compressé du plan d’exécution de requêtes dans le Magasin des requêtes, dans un attribut OptimizationReplay caché.
EXPAND VIEWS
Indique que les vues indexées doivent être développées, spécifie aussi que l’optimiseur de requête ne doit pas prendre en compte les vues indexées en remplacement d’une partie de la requête. Une vue est développée lorsque sa définition remplace son nom dans le texte de la requête.
Cet indicateur de requête interdit virtuellement l'utilisation directe de vues indexées et d'index sur des vues indexées dans le plan de requête.
Notes
La vue indexée reste condensée si une référence directe y est faite dans la partie SELECT de la requête, La vue reste également condensée si vous spécifiez WITH (NOEXPAND) ou WITH (NOEXPAND, INDEX( <index_value> [ , *...n* ] ) ). Pour plus d’informations sur l’indicateur de requête NOEXPAND, consultez Utilisation de NOEXPAND.
L'indicateur n’a d’incidence que sur les vues de la partie SELECT des instructions, y compris celles figurant dans des instructions INSERT, UPDATE, MERGE et DELETE.
FAST <integer_value>
Spécifie que la requête est optimisée pour la récupération rapide des <integer_value> premières lignes. Ce résultat est un entier non négatif. Une fois que les premières lignes définies par <integer_value> ont été retournées, la requête se poursuit pour retourner un jeu de résultats complet.
FORCE ORDER
Spécifie que l'ordre de jointure spécifié dans la syntaxe de la requête est conservé au cours de l'optimisation de la requête. FORCE ORDER n’a aucun effet sur un éventuel comportement d’inversion des rôles de la part de l’optimiseur de requête.
Notes
Dans une instruction MERGE, il convient d'accéder à la table source avant la table cible comme ordre de jointure par défaut, à moins que la clause WHEN SOURCE NOT MATCHED ne soit spécifiée. La spécification de FORCE ORDER préserve ce comportement par défaut.
{ FORCE | DISABLE } EXTERNALPUSHDOWN
Force ou désactive la poussée vers le bas (pushdown) du calcul des expressions éligibles dans Hadoop. S’applique uniquement aux requêtes avec PolyBase. Ne s’applique pas au stockage Azure.
{ FORCE | DISABLE } SCALEOUTEXECUTION
Forcez ou désactivez l’exécution avec montée en puissance parallèle des requêtes PolyBase qui utilisent des tables externes dans SQL Server 2019 Clusters Big Data. Cet indicateur n’est respecté que par une requête utilisant l’instance maître d’un cluster Big Data SQL. Le scale-out se produit dans le pool de calcul du cluster Big Data.
KEEP PLAN
Modifie les seuils de recompilation des tables temporaires et les rend identiques à ceux des tables permanentes. Le seuil de recompilation estimé lance une recompilation automatique de la requête lorsque le nombre estimé de modifications de colonnes indexées a été apporté à une table par exécution de l’une des instructions suivantes :
- UPDATE
- Suppression
- MERGE
- INSERT
La spécification de KEEP PLAN permet de garantir qu’une requête n’est pas recompilée aussi fréquemment quand plusieurs mises à jour sont effectuées dans une table.
KEEPFIXED PLAN
Force l’optimiseur de requête à ne pas recompiler une requête en raison de modifications enregistrées au niveau des statistiques. L’indication de KEEPFIXED PLAN permet de garantir qu’une requête n’est recompilée que si le schéma des tables sous-jacentes est modifié ou si sp_recompile s’exécute sur ces tables.
IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX
S’applique à : SQL Server (à compter de SQL Server 2012 (11.x)).
Empêche la requête d’utiliser un index columnstore non-cluster à mémoire optimisée. Si la requête contient l’indicateur de requête pour éviter l’utilisation de l’index columnstore et un indicateur d’index pour utiliser un index columnstore, les indicateurs sont en conflit et la requête retourne une erreur.
MAX_GRANT_PERCENT = <numeric_value>
S’applique à : SQL Server (à partir de SQL Server 2012 (11.x) Service Pack 3, SQL Server 2014 (12.x) Service Pack 2 et Azure SQL Database.
Taille maximale d’allocation de mémoire en pourcentage de la limite de mémoire configurée. La requête est garantie de ne pas dépasser cette limite si elle s’exécute dans une liste de ressources partagées définie par l’utilisateur. Dans ce cas, si la requête ne dispose pas de la mémoire minimale requise, le système génère une erreur. Si une requête s’exécute dans le pool système (par défaut), elle disposera au minimum de la mémoire requise pour s’exécuter. La limite réelle peut être inférieure si le paramètre de Resource Governor est inférieur à la valeur spécifiée par cet indicateur. Les valeurs valides sont comprises entre 0,0 et 100,0.
L’indicateur d’allocation de mémoire n’est pas disponible pour la création d’index ou la reconstruction d’index.
MIN_GRANT_PERCENT = <numeric_value>
S’applique à : SQL Server (à partir de SQL Server 2012 (11.x) Service Pack 3, SQL Server 2014 (12.x) Service Pack 2 et Azure SQL Database.
Taille minimale d’allocation de mémoire en pourcentage de la limite de mémoire configurée. La requête est assurée d’avoir au moins MAX(required memory, min grant), car la mémoire nécessaire est le minimum requis pour pouvoir démarrer une requête. Les valeurs valides sont comprises entre 0,0 et 100,0.
L’option d’octroi de mémoire min_grant_percent remplace l’option sp_configure (mémoire minimale par requête (base de connaissance)) quelle que soit la taille. L’indicateur d’allocation de mémoire n’est pas disponible pour la création d’index ou la reconstruction d’index.
MAXDOP <integer_value>
S’applique à : SQL Server (à compter de SQL Server 2008 (10.0.x)) et Azure SQL Database.
Remplace l’option de configuration Degré maximal de parallélisme de sp_configure. Remplace également Resource Governor 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 Resource Governor, le moteur de base de données utilise la valeur MAXDOP de Resource Governor, décrite dans ALTER WORKLOAD GROUP (Transact-SQL). Toutes les règles sémantiques utilisées avec l’option de configuration max degree of parallelism sont applicables quand vous utilisez l’indicateur de requête MAXDOP. Pour plus d’informations, consultez Configurer l’option de configuration du serveur max degree of parallelism.
Avertissement
Si MAXDOP a la valeur zéro, le serveur choisit le degré maximal de parallélisme.
MAXRECURSION <integer_value>
Spécifie le nombre maximal de récursivités autorisé pour cette requête. number est un entier non négatif compris entre 0 et 32 767. Lorsque 0 est spécifié, aucune limite n'est appliquée. Si cette option n'est pas spécifiée, la limite par défaut du serveur est 100.
Lorsque la limite par défaut ou spécifiée de MAXRECURSION est atteinte au cours de l'exécution d'une requête, cette requête se termine en retournant une erreur.
À cause de cette erreur, tous les effets de l'instruction sont annulés. Si l’instruction est une instruction SELECT, des résultats partiels ou aucun résultat peut être retourné. Les résultats partiels retournés peuvent ne pas inclure toutes les lignes sur les niveaux de récursivité au-delà du niveau de récursivité maximal spécifié.
Pour plus d’informations, consultez WITH common_table_expression (Transact-SQL).
NO_PERFORMANCE_SPOOL
S’applique à : SQL Server (à compter de SQL Server 2016 (13.x)) et Azure SQL Database.
Empêche l’ajout d’un opérateur de spool aux plans de requête (à l’exception des plans où un spool est nécessaire pour garantir la validité de la sémantique de mise à jour). L’opérateur depool peut réduire les performances dans certains scénarios. Par exemple, le spool utilise tempdb et la contention tempdb peut se produire quand un grand nombre de requêtes simultanées sont exécutées avec les opérations de spool.
OPTIMIZE FOR ( @variable_name { UNKNOWN | = <literal_constant> } [ , ...n ] )
Indique à l’optimiseur de requête d’attribuer à une variable locale une valeur déterminée lors de la compilation et de l’optimisation de la requête. Cette valeur n'est utilisée que pendant l'optimisation de la requête, et non pas lors de son exécution.
@variable_name
Nom d’une variable locale utilisée dans une requête, auquel une valeur peut être affectée pour une utilisation avec l’indicateur de requête OPTIMIZE FOR.
UNKNOWN
Spécifie que l’optimiseur de requête utilise des données statistiques à la place de la valeur initiale pour déterminer la valeur d’une variable locale pendant l’optimisation de requête.
<literal_constant>
Valeur de constante littérale à laquelle attribuer @variable_name pour l’utiliser avec l’indicateur de requête OPTIMIZE FOR. <literal_constant> n’est utilisé que pendant l’optimisation de la requête, et non comme valeur de @variable_name lors de l’exécution de la requête. <literal_constant> peut être de n’importe quel type de données système SQL Server qui peut être exprimé sous forme de constante littérale. Le type de données de <literal_constant> doit être implicitement convertible dans le type de données auquel @variable_name fait référence dans la requête.
OPTIMIZE FOR peut contrecarrer le comportement de détection des paramètres par défaut de l’optimiseur. Utilisez également OPTIMIZE FOR pour créer des repères de plan. Pour plus d’informations, consultez Recompiler une procédure stockée.
OPTIMIZE FOR UNKNOWN
Indique à l’optimiseur de requête d’utiliser la sélectivité moyenne du prédicat sur toutes les valeurs de colonne au lieu d’utiliser la valeur du paramètre de runtime lorsque la requête est compilée et optimisée.
Si vous utilisez OPTIMIZE FOR @variable_name = <literal_constant> et OPTIMIZE FOR UNKNOWN dans le même indicateur de requête, l’optimiseur de requête utilise la literal_constant spécifiée pour une valeur spécifique. L’optimiseur de requête utilise UNKNOWN pour les autres valeurs des variables. Les valeurs ne sont utilisées que pendant l'optimisation de la requête, et non pas lors de son exécution.
PARAMETERIZATION { SIMPLE | FORCED }
Spécifie les règles de paramétrage que l’optimiseur de requête SQL Server doit appliquer à la requête lors de sa compilation.
Important
L’indicateur de requête PARAMETERIZATION peut uniquement être spécifié à l’intérieur d’un repère de plan pour remplacer le paramètre actuel de l’option SET de base de données PARAMETERIZATION. Il n’est pas possible de le spécifier directement dans une requête.
Pour plus d’informations, consultez Spécifier le comportement du paramétrage de requêtes grâce aux repères de plan.
SIMPLE indique à l’optimiseur de requête de tenter un paramétrage simple. FORCED indique à l’optimiseur de requête de tenter un paramétrage forcé. Pour plus d’informations, consultez Paramétrage forcé dans le Guide d’architecture de traitement des requêtes et Paramétrage simple dans le Guide d’architecture de traitement des requêtes.
QUERYTRACEON <integer_value>
Cette option vous permet d’activer un indicateur de trace affectant le plan uniquement pendant la compilation d’une requête unique. Comme d’autres options de niveau requête, vous pouvez l’utiliser avec des repères de plan pour faire correspondre le texte d’une requête en cours d’exécution à partir de n’importe quelle session, et appliquer automatiquement un indicateur de trace affectant le plan lorsque cette requête est en cours de compilation. L’option QUERYTRACEON est prise en charge seulement pour les indicateurs de trace de l’optimiseur de requête. Pour plus d’informations, consultez l’article Indicateurs de trace.
L’utilisation de cette option ne retourne pas d’erreur ni d’avertissement si un numéro d’indicateur de trace non pris en charge est utilisé. Si l’indicateur de trace spécifié n’est pas celui qui affecte un plan d’exécution de requête, l’option est ignorée en mode silencieux.
Pour utiliser plusieurs indicateurs de trace dans une requête, spécifiez un indicateur QUERYTRACEON pour chaque numéro d’indicateur de trace.
RECOMPILE
Envoie à Moteur de base de données SQL Server l’instruction de générer un nouveau plan temporaire pour la requête et de l’abandonner juste après la fin d’exécution de la requête. Le plan de requête généré ne remplace pas un plan stocké en cache lorsque la même requête s’exécute sans l’indicateur RECOMPILE. Si RECOMPILE n’est pas spécifié, le Moteur de base de données met en cache les plans de requête et les réutilise. Lors de la compilation de plans de requête, l’indicateur de requête RECOMPILE utilise les valeurs actuelles des éventuelles variables locales dans la requête. Si la requête se trouve à l’intérieur d’une procédure stockée, les valeurs actuelles sont transmises aux paramètres.
RECOMPILE est utile pour ne pas avoir à créer une procédure stockée. RECOMPILE utilise la clause WITH RECOMPILE lorsqu'il s'agit seulement de recompiler un sous-ensemble de requêtes dans la procédure stockée, et non la totalité de celle-ci. Pour plus d’informations, consultez Recompiler une procédure stockée. RECOMPILE s'avère également utile pour créer des repères de guides.
ROBUST PLAN
Force l’optimiseur de requête à essayer un plan capable de prendre en charge la taille maximale potentielle des lignes, éventuellement aux dépens des performances. Lorsque la requête est traitée, les tables et opérateurs intermédiaires peuvent devoir stocker et traiter des lignes plus larges que l’une des lignes d’entrée lorsque la requête est traitée. Les lignes peuvent être si larges que, parfois, l’opérateur particulier ne peut pas traiter la ligne. Dans ce cas, le Moteur de base de données génère une erreur lors de l'exécution de la requête. En utilisant ROBUST PLAN, vous demandez à l’optimiseur de requête de ne pas prendre en compte les plans de requête susceptibles d’être rencontrés dans ce problème.
Si un tel plan n’est pas possible, l’optimiseur de requête retourne une erreur plutôt que de différer la détection de l’erreur au moment de l’exécution de la requête. Les lignes peuvent contenir des colonnes de longueur variable ; l’Moteur de base de données permet de définir des lignes qui ont une taille potentielle maximale au-delà de la capacité de la Moteur de base de données de les traiter. En règle générale, en dépit de la taille maximale potentielle, une application stocke des lignes dont la taille réelle est comprise dans les limites gérées par le Moteur de base de données. Si Moteur de base de données rencontre une ligne trop longue, il retourne une erreur d'exécution.
USE HINT ( 'hint_name' )
S’applique à : SQL Server (depuis SQL Server 2016 (13.x) SP1) et Azure SQL Database.
Fournit au processeur de requêtes un ou plusieurs indicateurs supplémentaires, spécifiés par un nom entre guillemets simples.
Les noms d’indicateur suivants sont pris en charge :
'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'
Indique à SQL Server de générer un plan de requête qui utilise l’hypothèse de relation contenant-contenu simple, au lieu de l’hypothèse par défaut de relation contenant-contenu de base pour les jointures, avec le modèle d’estimation de la cardinalité de l’optimiseur de requête fourni dans SQL Server 2014 (12.x) ou ultérieur. Ce nom d’indicateur équivaut à l’indicateur de trace 9476.
'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES'
Indique à SQL Server de générer un plan qui utilise la sélectivité minimale lors de l’évaluation des prédicats AND des filtres pour la prise en compte de la corrélation complète. Ce nom d’indicateur équivaut à l’indicateur de trace 4137 avec le modèle d’estimation de la cardinalité fourni dans SQL Server 2012 (11.x) et les versions antérieures, ou à l’indicateur de trace 9471 avec le modèle d’estimation de la cardinalité disponible dans SQL Server 2014 (12.x) ou versions ultérieures.
'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES'
Indique à SQL Server de générer un plan qui utilise la sélectivité maximale lors de l’évaluation des prédicats AND des filtres pour la prise en compte de l’indépendance complète. Ce nom d’indicateur est le comportement par défaut du modèle d’estimation de la cardinalité fourni dans SQL Server 2012 (11.x) et les versions antérieures et équivaut à l’indicateur de trace 9472 quand il est utilisé avec le modèle d’estimation de la cardinalité disponible dans SQL Server 2014 (12.x) ou versions ultérieures.
S’applique à : Azure SQL Database
'ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES'
Indique à SQL Server de générer un plan qui utilise une sélectivité de la plus forte à la moins forte lors de l’évaluation des prédicats AND des filtres pour la prise en compte de la corrélation partielle. Ce nom d’indicateur est le comportement par défaut du modèle d’estimation de la cardinalité disponible dans SQL Server 2014 (12.x) ou versions ultérieures.
S’applique à : Azure SQL Database
'DISABLE_BATCH_MODE_ADAPTIVE_JOINS'
Désactive les jointures adaptatives en mode batch. Pour plus d’informations, consultez Jointures adaptatives en mode batch.
S’applique à : SQL Server (à compter de SQL Server 2017 (14.x)) et Azure SQL Database
'DISABLE_BATCH_MODE_MEMORY_GRANT_FEEDBACK'
Désactive les retours d’allocation de mémoire en mode batch. Pour plus d’informations, consultez Retour d’allocation de mémoire en mode batch.
S’applique à : SQL Server (à compter de SQL Server 2017 (14.x)) et Azure SQL Database
'DISABLE_DEFERRED_COMPILATION_TV'
Désactive la compilation différée de variable de table. Pour plus d'informations, consultez Compilation différée de variable de table.
S’applique à : SQL Server (à compter de SQL Server 2019 (15.x)) et Azure SQL Database
'DISABLE_INTERLEAVED_EXECUTION_TVF'
Désactive l’exécution entrelacée pour les fonctions table à instructions multiples. Pour plus d’informations, voir Exécution entrelacée pour les fonctions table à instructions multiples.
S’applique à : SQL Server (à compter de SQL Server 2017 (14.x)) et Azure SQL Database
'DISABLE_OPTIMIZED_NESTED_LOOP'
Indique au processeur de requêtes de ne pas appliquer d’opération de tri (tri par lots) sur les jointures de boucles imbriquées optimisées au moment de la génération d’un plan de requête. Ce nom d’indicateur équivaut à l’indicateur de trace 2340.
-
Indique à SQL Server de générer un plan qui n’utilise pas les modifications de l’objectif des lignes avec des requêtes contenant ces mots clés :
- Haut de la page
- OPTION (FAST N)
- IN
- EXISTS
Ce nom d’indicateur équivaut à l’indicateur de trace 4138.
'DISABLE_PARAMETER_SNIFFING'
Indique à l’optimiseur de requête d’utiliser la distribution moyenne des données lors de la compilation d’une requête comportant un ou plusieurs paramètres. Cette instruction rend le plan de requête indépendant de la valeur du paramètre utilisée initialement lors de la compilation de la requête. Ce nom d’indicateur équivaut à l’indicateur de trace 4136 ou au paramètre de configuration au niveau base de données
PARAMETER_SNIFFING = OFF.'DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK'
Désactive la rétroaction d’allocation de mémoire en mode ligne. Pour plus d’informations, consultez Rétroaction d’allocation de mémoire en mode ligne.
S’applique à : SQL Server (à compter de SQL Server 2019 (15.x)) et Azure SQL Database
'DISABLE_TSQL_SCALAR_UDF_INLINING'
Désactive l’incorporation des fonctions UDF scalaires. Pour plus d’informations, consultez Incorporation des fonctions UDF scalaires.
S’applique à : SQL Server (à compter de SQL Server 2019 (15.x)) et Azure SQL Database
'DISALLOW_BATCH_MODE'
Désactive l’exécution en mode batch. Pour plus d’informations, consultez Modes d’exécution.
S’applique à : SQL Server (à compter de SQL Server 2019 (15.x)) et Azure SQL Database
'ENABLE_HIST_AMENDMENT_FOR_ASC_KEYS'
Active automatiquement la génération de statistiques rapides (modification de l’histogramme) pour les colonnes d’index de début où l’estimation de la cardinalité est nécessaire. L’histogramme utilisé pour estimer la cardinalité est ajusté au moment de la compilation des requêtes pour prendre en compte la valeur minimale ou maximale réelle de chaque colonne. Ce nom d’indicateur équivaut à l’indicateur de trace 4139.
'ENABLE_QUERY_OPTIMIZER_HOTFIXES'
Active les correctifs de l’optimiseur de requête (modifications publiées dans les Service Packs et mises à jour cumulatives de SQL Server). Ce nom d’indicateur équivaut à l’indicateur de trace 4199 ou au paramètre de configuration au niveau base de données
QUERY_OPTIMIZER_HOTFIXES = ON.'FORCE_DEFAULT_CARDINALITY_ESTIMATION'
Force l’optimiseur de requête à utiliser le modèle d’estimation de la cardinalité qui correspond au niveau de compatibilité de la base de données. Cet indicateur remplace le paramètre de configuration au niveau base de données
LEGACY_CARDINALITY_ESTIMATION = ONou l’indicateur de trace 9481.'FORCE_LEGACY_CARDINALITY_ESTIMATION'
Force l’optimiseur de requête à utiliser le modèle Estimation de cardinalité fourni dans SQL Server 2012 (11.x) et les versions antérieures. Ce nom d’indicateur équivaut à l’indicateur de trace 9481 ou au paramètre de configuration au niveau base de données
LEGACY_CARDINALITY_ESTIMATION = ON.'QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n'
Force le comportement de l’optimiseur de requête au niveau de la requête, comme si celle-ci était compilée avec le niveau de compatibilité de la base de données n, où n est un niveau pris en charge (par exemple 100, 130, etc.). Consultez sys.dm_exec_valid_use_hints pour obtenir la liste des valeurs actuellement prises en charge pour n.
S’applique à : SQL Server (depuis SQL Server 2017 (14.x) CU10) et Azure SQL Database
Notes
L’indicateur QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n ne remplace pas le paramètre d’estimation de la cardinalité hérité ou par défaut, s’il est forcé par le biais de la configuration de portée de base de données, l’indicateur de trace ou un autre indicateur de requête comme QUERYTRACEON.
Cet indicateur affecte uniquement le comportement de l’optimiseur de requête. Il n’a aucun effet sur les autres fonctionnalités de SQL Server susceptibles de dépendre du niveau de compatibilité de la base de données, comme la disponibilité de certaines fonctionnalités de la base de données.
Pour en savoir plus sur cet indicateur, consultez Developer’s Choice: Hinting Query Execution model.'QUERY_PLAN_PROFILE'
Permet un profilage léger pour la requête. À la fin d’une requête contenant ce nouvel indicateur, un nouvel événement étendu, query_plan_profile, est déclenché. Cet événement étendu expose les statistiques d’exécution et le plan d’exécution réel XML semblable à l’événement étendu query_post_execution_showplan, mais uniquement pour les requêtes qui contiennent le nouvel indicateur.
S’applique à : SQL Server (à partir de SQL Server 2016 (13.x) SP2CU3 et SQL Server 2017 (14.x) CU11).
Remarque
Si vous activez la collecte de l’événement
query_post_execution_showplanétendu, cela ajoute une infrastructure de profilage standard à chaque requête exécutée sur le serveur et peut donc affecter les performances globales du serveur.
Si vous activez plutôt la collecte d’événementsquery_thread_profileétendus pour utiliser une infrastructure de profilage légère, cela entraîne une surcharge de performances beaucoup moins importante, mais affecte toujours les performances globales du serveur.
Si vous activez l’événementquery_plan_profileétendu, cela active uniquement l’infrastructure de profilage légère pour une requête exécutée avec lequery_plan_profileserveur et n’affecte donc pas d’autres charges de travail sur le serveur. Utilisez cet indicateur pour profiler une requête spécifique sans affecter d’autres parties de la charge de travail du serveur. Pour en savoir plus sur le profilage léger, consultez Infrastructure du profilage de requête.
Vous pouvez obtenir la liste de tous les noms d’indicateur USE HINT pris en charge en effectuant une requête sur la vue de gestion dynamique sys.dm_exec_valid_use_hints.
Conseil
Les noms d’indicateur respectent la casse.
Important
Certains indicateurs USE HINT peuvent entrer en conflit avec les indicateurs de trace activés au niveau global ou de session, ou des paramètres de configuration délimités à la base de données. Dans ce cas, l’indicateur de niveau requête (USE HINT) est toujours prioritaire. En présence d’un conflit entre l’indicateur USE HINT et un autre indicateur de requête ou un indicateur de trace activé au niveau requête (par exemple, par QUERYTRACEON), SQL Server génère une erreur quand vous tentez d’exécuter la requête.
USE PLAN N'<xml_plan>'
Force l’optimiseur de requête à utiliser un plan de requête existant pour une requête spécifiée par <xml_plan>. Il n’est pas possible de spécifier USE PLAN avec des instructions INSERT, UPDATE, MERGE ou DELETE.
Le plan d’exécution obtenu, qui est forcé par cette fonctionnalité, est le même que le plan forcé ou est similaire à celui-ci. Étant donné que le plan résultant peut ne pas être identique au plan spécifié par USE PLAN, les performances des plans peuvent varier. Dans de rares cas, la différence de performances peut être significative et négative ; dans ce cas, l’administrateur doit supprimer le plan forcé.
TABLE HINT (<exposed_object_name> [ , <table_hint> [ [, ]...n ] ] )
Applique l’indicateur de table spécifié à la table ou vue qui correspond à exposed_object_name. Nous vous recommandons d’utiliser un indicateur de table comme indicateur de requête uniquement dans le contexte d’un repère de plan.
<exposed_object_name> peut être l’une des références suivantes :
Quand un alias est utilisé pour la table ou la vue dans la clause FROM de la requête, exposed_object_name est l’alias.
Si aucun alias n’est utilisé, exposed_object_name est la correspondance exacte de la table ou vue référencée dans la clause FROM. Par exemple, si la table ou la vue est référencée à l’aide d’un nom en deux parties, exposed_object_name correspond au même nom en deux parties.
Si exposed_object_name est spécifié sans indicateur de table, tous les index indiqués dans la requête dans le cadre d’un indicateur de table de l’objet sont ignorés. L’optimiseur de requête détermine ensuite l’utilisation de l’index. Vous pouvez utiliser cette technique pour éliminer l'effet d'un indicateur de table INDEX lorsque vous ne pouvez pas modifier la requête d'origine. Voir l'exemple J.
<table_hint>
NOEXPAND [ , INDEX ( <index_value> [ ,... n ] ) | INDEX = ( <index_value> ) ] | INDEX ( <index_value> [ ,... n ] ) | INDEX = ( <index_value> ) | FORCESEEK [(<index_value>(<index_column_name> [,... ] ) ] | FORCESCAN | HOLDLOCK | NOLOCK | NOWAIT | PAGLOCK | READCOMMITTED | READCOMMITTEDLOCK | READPAST | READUNCOMMITTED | REPEATABLEREAD | ROWLOCK | SERIALIZABLE | INSTANTANÉ | SPATIAL_WINDOW_MAX_CELLS = <integer_value> | TABLOCK | TABLOCKX | UPDLOCK | XLOCK
Indicateur de table à appliquer à la table ou la vue qui correspond à exposed_object_name en tant qu'indicateur de requête. Pour obtenir une description de ces indicateurs, consultez Indicateurs de table (Transact-SQL).
Les indicateurs de table autres que INDEX, FORCESCAN et FORCESEEK sont interdits comme indicateurs de requête, à moins que la requête n'ait déjà une clause WITH qui spécifie l'indicateur de table. Pour plus d'informations, consultez la section Remarques.
Attention
Le fait de spécifier FORCESEEK avec des paramètres limite davantage le nombre de plans qui peuvent être considérés par l'optimiseur de requête que le fait de spécifier FORCESEEK sans paramètres. Cela peut entraîner une erreur « Impossible de générer un plan » dans d’autres cas.
Notes
Il n’est pas possible de spécifier des indicateurs de requête dans une instruction INSERT, sauf si celle-ci contient une clause SELECT.
Les indicateurs de requête ne peuvent être spécifiés que dans une requête de niveau supérieur et non pas dans des sous-requêtes. Lorsqu’un indicateur de table est spécifié comme indicateur de requête, il peut se trouver dans la requête de premier niveau ou dans une sous-requête. Toutefois, la valeur spécifiée pour <exposed_object_name> dans la clause TABLE HINT doit correspondre exactement au nom exposé dans la requête ou la sous-requête.
Spécifier les indicateurs de table comme indicateurs de requête
Nous vous recommandons d’utiliser l’indicateur de table INDEX, FORCESCAN ou FORCESEEK comme indicateur de requête uniquement dans le contexte d’un repère de plan. Les repères de plan sont utiles lorsqu’il n’est pas possible de modifier la requête d'origine, par exemple s’il s'agit d'une application tierce. L'indicateur de requête spécifié dans le repère de plan est ajouté à la requête avant sa compilation et son optimisation. Pour les requêtes ad hoc, utilisez la clause TABLE HINT uniquement lors du test des instructions de repère de plan. Pour toutes les autres requêtes ad hoc, nous recommandons de spécifier ces indicateurs uniquement comme indicateurs de table.
Lorsqu'ils sont spécifiés comme indicateurs de requête, les indicateurs de table INDEX, FORCESCAN et FORCESEEK sont valides pour les objets suivants :
- Tables
- Les vues
- Vues indexées
- Expressions de table communes (l'indicateur doit être spécifié dans l'instruction SELECT dont le jeu de résultats remplit l'expression de table commune)
- Vues de gestion dynamique
- Sous-requêtes nommées
Il est possible de spécifier des indicateurs de table INDEX, FORCESCAN et FORCESEEK comme indicateurs de requête pour une requête ne disposant pas d’indicateurs de table. Vous pouvez également les utiliser pour remplacer respectivement des indicateurs INDEX, FORCESCAN et FORCESEEK existants dans la requête.
Les indicateurs de table autres que INDEX, FORCESCAN et FORCESEEK sont interdits comme indicateurs de requête, à moins que la requête n'ait déjà une clause WITH qui spécifie l'indicateur de table. Dans ce cas, il faut également spécifier un indicateur correspondant comme indicateur de requête. Utilisez pour cela TABLE HINT dans la clause OPTION. Cette spécification préserve la sémantique de la requête. Par exemple, si la requête contient l’indicateur de table NOLOCK, la clause OPTION dans le paramètre @hints du repère de plan doit également contenir l’indicateur NOLOCK. Voir l'exemple K.
Spécifier des conseils avec les indicateurs du Magasin des requêtes
Vous pouvez appliquer des indicateurs sur les requêtes identifiées par le biais du Magasin des requêtes sans apporter de modifications au code, en utilisant la fonctionnalité Indicateurs du Magasin des requêtes. Utilisez la procédure stockée sys.sp_query_store_set_hints pour appliquer un indicateur à une requête. Consultez l’exemple N.
Exemples
R. Utiliser MERGE JOIN
L’exemple suivant spécifie que MERGE JOIN exécute l’opération JOIN dans la requête. L'exemple utilise la base de données AdventureWorks2022.
SELECT *
FROM Sales.Customer AS c
INNER JOIN Sales.CustomerAddress AS ca ON c.CustomerID = ca.CustomerID
WHERE TerritoryID = 5
OPTION (MERGE JOIN);
GO
B. Utiliser OPTIMIZE FOR
L’exemple suivant indique à l’optimiseur de requête d’utiliser la valeur 'Seattle' pour @city_name et d’utiliser la sélectivité moyenne du prédicat sur toutes les valeurs de colonne pour @postal_code lors de l’optimisation de la requête. L'exemple utilise la base de données AdventureWorks2022.
CREATE PROCEDURE dbo.RetrievePersonAddress
@city_name NVARCHAR(30),
@postal_code NVARCHAR(15)
AS
SELECT * FROM Person.Address
WHERE City = @city_name AND PostalCode = @postal_code
OPTION ( OPTIMIZE FOR (@city_name = 'Seattle', @postal_code UNKNOWN) );
GO
C. Utiliser MAXRECURSION
MAXRECURSION peut être utilisé pour empêcher une expression de table commune récursive mal rédigée d'entrer dans une boucle infinie. L’exemple suivant créée intentionnellement une boucle infinie et utilise l’indicateur MAXRECURSION pour limiter le nombre de niveaux de récursivité à deux. L'exemple utilise la base de données AdventureWorks2022.
--Creates an infinite loop
WITH cte (CustomerID, PersonID, StoreID) AS
(
SELECT CustomerID, PersonID, StoreID
FROM Sales.Customer
WHERE PersonID IS NOT NULL
UNION ALL
SELECT cte.CustomerID, cte.PersonID, cte.StoreID
FROM cte
JOIN Sales.Customer AS e
ON cte.PersonID = e.CustomerID
)
--Uses MAXRECURSION to limit the recursive levels to 2
SELECT CustomerID, PersonID, StoreID
FROM cte
OPTION (MAXRECURSION 2);
GO
Une fois l'erreur de codage corrigée, MAXRECURSION n'est plus nécessaire.
D. Utiliser MERGE UNION
L’exemple suivant utilise l’indicateur de requête MERGE UNION. L'exemple utilise la base de données AdventureWorks2022.
SELECT *
FROM HumanResources.Employee AS e1
UNION
SELECT *
FROM HumanResources.Employee AS e2
OPTION (MERGE UNION);
GO
E. Utiliser HASH GROUP et FAST
L’exemple suivant utilise les indicateurs de requête HASH GROUP et FAST. L'exemple utilise la base de données AdventureWorks2022.
SELECT ProductID, OrderQty, SUM(LineTotal) AS Total
FROM Sales.SalesOrderDetail
WHERE UnitPrice < $5.00
GROUP BY ProductID, OrderQty
ORDER BY ProductID, OrderQty
OPTION (HASH GROUP, FAST 10);
GO
F. Utiliser MAXDOP
L’exemple suivant utilise l’indicateur de requête MAXDOP. L'exemple utilise la base de données AdventureWorks2022.
SELECT ProductID, OrderQty, SUM(LineTotal) AS Total
FROM Sales.SalesOrderDetail
WHERE UnitPrice < $5.00
GROUP BY ProductID, OrderQty
ORDER BY ProductID, OrderQty
OPTION (MAXDOP 2);
GO
G. Utiliser INDEX
Les exemples suivants utilisent l'indicateur INDEX. Le premier exemple spécifie un index unique. Le deuxième exemple spécifie plusieurs index pour une référence de table individuelle. Dans les deux exemples, étant donné que l'indicateur INDEX est appliqué à une table qui utilise un alias, la clause TABLE HINT doit également spécifier le même alias que le nom d'objet exposé. L'exemple utilise la base de données AdventureWorks2022.
EXEC sp_create_plan_guide
@name = N'Guide1',
@stmt = N'SELECT c.LastName, c.FirstName, e.Title
FROM HumanResources.Employee AS e
JOIN Person.Contact AS c ON e.ContactID = c.ContactID
WHERE e.ManagerID = 2;',
@type = N'SQL',
@module_or_batch = NULL,
@params = NULL,
@hints = N'OPTION (TABLE HINT(e, INDEX (IX_Employee_ManagerID)))';
GO
EXEC sp_create_plan_guide
@name = N'Guide2',
@stmt = N'SELECT c.LastName, c.FirstName, e.Title
FROM HumanResources.Employee AS e
JOIN Person.Contact AS c ON e.ContactID = c.ContactID
WHERE e.ManagerID = 2;',
@type = N'SQL',
@module_or_batch = NULL,
@params = NULL,
@hints = N'OPTION (TABLE HINT(e, INDEX(PK_Employee_EmployeeID, IX_Employee_ManagerID)))';
GO
H. Utiliser FORCESEEK
L'exemple suivant utilise l'indicateur de table FORCESEEK. La clause TABLE HINT doit également spécifier le même nom en deux parties que le nom d’objet exposé. Indiquez ce nom lorsque vous appliquez l’indicateur INDEX à une table qui utilise un nom en deux parties. L'exemple utilise la base de données AdventureWorks2022.
EXEC sp_create_plan_guide
@name = N'Guide3',
@stmt = N'SELECT c.LastName, c.FirstName, HumanResources.Employee.Title
FROM HumanResources.Employee
JOIN Person.Contact AS c ON HumanResources.Employee.ContactID = c.ContactID
WHERE HumanResources.Employee.ManagerID = 3
ORDER BY c.LastName, c.FirstName;',
@type = N'SQL',
@module_or_batch = NULL,
@params = NULL,
@hints = N'OPTION (TABLE HINT( HumanResources.Employee, FORCESEEK))';
GO
I. Utiliser plusieurs indicateurs de table
L'exemple suivant applique l'indicateur INDEX à une table et l'indicateur FORCESEEK à une autre. L'exemple utilise la base de données AdventureWorks2022.
EXEC sp_create_plan_guide
@name = N'Guide4',
@stmt = N'SELECT e.ManagerID, c.LastName, c.FirstName, e.Title
FROM HumanResources.Employee AS e
JOIN Person.Contact AS c ON e.ContactID = c.ContactID
WHERE e.ManagerID = 3;',
@type = N'SQL',
@module_or_batch = NULL,
@params = NULL,
@hints = N'OPTION (TABLE HINT (e, INDEX( IX_Employee_ManagerID))
, TABLE HINT (c, FORCESEEK))';
GO
J. Utiliser TABLE HINT pour substituer un indicateur de table existant
L’exemple suivant montre comment se servir de l’indicateur TABLE HINT. Vous pouvez l’utiliser sans spécifier d’indicateur pour remplacer le comportement de l’indicateur de table INDEX spécifié dans la clause FROM de la requête. L'exemple utilise la base de données AdventureWorks2022.
EXEC sp_create_plan_guide
@name = N'Guide5',
@stmt = N'SELECT e.ManagerID, c.LastName, c.FirstName, e.Title
FROM HumanResources.Employee AS e WITH (INDEX (IX_Employee_ManagerID))
JOIN Person.Contact AS c ON e.ContactID = c.ContactID
WHERE e.ManagerID = 3;',
@type = N'SQL',
@module_or_batch = NULL,
@params = NULL,
@hints = N'OPTION (TABLE HINT(e))';
GO
K. Spécifier des indicateurs de table affectant la sémantique
L’exemple suivant contient deux indicateurs de table dans la requête : NOLOCK, qui affecte la sémantique, et INDEX, qui n’affecte pas la sémantique. Pour préserver la sémantique de la requête, l'indicateur NOLOCK est spécifié dans la clause OPTIONS du repère de plan. En parallèle de l'indicateur NOLOCK, spécifiez les indicateurs INDEX et FORCESEEK pour remplacer l'indicateur INDEX sans effet sur la sémantique dans la requête lors de la compilation et de l’optimisation de l'instruction. L'exemple utilise la base de données AdventureWorks2022.
EXEC sp_create_plan_guide
@name = N'Guide6',
@stmt = N'SELECT c.LastName, c.FirstName, e.Title
FROM HumanResources.Employee AS e
WITH (NOLOCK, INDEX (PK_Employee_EmployeeID))
JOIN Person.Contact AS c ON e.ContactID = c.ContactID
WHERE e.ManagerID = 3;',
@type = N'SQL',
@module_or_batch = NULL,
@params = NULL,
@hints = N'OPTION (TABLE HINT (e, INDEX(IX_Employee_ManagerID), NOLOCK, FORCESEEK))';
GO
L'exemple suivant indique une autre méthode pour préserver la sémantique de la requête et permettre à l'optimiseur de choisir un index autre que l'index spécifié dans l'indicateur de table. Autorisez l’optimiseur à choisir en spécifiant l’indicateur NOLOCK dans la clause OPTIONS. En effet, cet indicateur affecte la sémantique. Ensuite, indiquez le mot clé TABLE HINT avec seulement une référence de table, sans indicateur INDEX. L'exemple utilise la base de données AdventureWorks2022.
EXEC sp_create_plan_guide
@name = N'Guide7',
@stmt = N'SELECT c.LastName, c.FirstName, e.Title
FROM HumanResources.Employee AS e
WITH (NOLOCK, INDEX (PK_Employee_EmployeeID))
JOIN Person.Contact AS c ON e.ContactID = c.ContactID
WHERE e.ManagerID = 2;',
@type = N'SQL',
@module_or_batch = NULL,
@params = NULL,
@hints = N'OPTION (TABLE HINT (e, NOLOCK))';
GO
L. Utiliser USE HINT
L’exemple suivant utilise les indicateurs de requête RECOMPILE et USE HINT. L'exemple utilise la base de données AdventureWorks2022.
SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (RECOMPILE, USE HINT ('ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES', 'DISABLE_PARAMETER_SNIFFING'));
GO
M. Utiliser QUERYTRACEON HINT
L’exemple suivant utilise les indicateurs de requête QUERYTRACEON. L'exemple utilise la base de données AdventureWorks2022. Vous pouvez activer tous les correctifs affectant le plan contrôlés par l’indicateur de trace 4199 pour une requête particulière avec la requête suivante :
SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (QUERYTRACEON 4199);
Vous pouvez également utiliser plusieurs indicateurs de trace comme dans la requête suivante :
SELECT * FROM Person.Address
WHERE City = 'SEATTLE' AND PostalCode = 98104
OPTION (QUERYTRACEON 4199, QUERYTRACEON 4137);
N. Utiliser les indicateurs du Magasin des requêtes
La fonctionnalité Indicateurs du Magasin des requêtes dans Azure SQL Database fournit une méthode facile à utiliser pour mettre en forme les plans de requête sans changer le code de l’application.
Tout d’abord, identifiez la requête qui a déjà été exécutée dans les vues catalogue du Magasin des requêtes, par exemple :
SELECT q.query_id, qt.query_sql_text
FROM sys.query_store_query_text qt
INNER JOIN sys.query_store_query q ON
qt.query_text_id = q.query_text_id
WHERE query_sql_text like N'%ORDER BY ListingPrice DESC%'
AND query_sql_text not like N'%query_store%';
GO
L’exemple suivant applique l’indicateur pour imposer l’estimateur de cardinalité hérité à query_id 39, identifié dans le Magasin des requêtes :
EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(USE HINT(''FORCE_LEGACY_CARDINALITY_ESTIMATION''))';
L’exemple suivant applique l’indicateur pour imposer une taille d’allocation de mémoire maximale en pourcentage (PERCENT) de la limite de mémoire configurée à query_id 39, identifié dans le Magasin des requêtes :
EXEC sys.sp_query_store_set_hints @query_id= 39, @query_hints = N'OPTION(MAX_GRANT_PERCENT=10)';
L’exemple suivant applique plusieurs indicateurs de requête à query_id 39, notamment RECOMPILE, MAXDOP 1 et le comportement de l’optimiseur de requête SQL 2012 :
EXEC sys.sp_query_store_set_hints @query_id= 39,
@query_hints = N'OPTION(RECOMPILE, MAXDOP 1, USE HINT(''QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_110''))';
Contenu connexe
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour