Indicateurs de requête (Transact-SQL)

Article
11/19/2024

S’applique à : SQL Server Azure SQL Database Azure SQL Managed Instance Base de données SQL dans Microsoft Fabric

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 UNION elle est impliquée dans la requête principale, seule la dernière requête impliquant une UNION opération peut avoir la OPTION clause. 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 ] ] )
  | FOR TIMESTAMP AS OF '<point_in_time>'
}

<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'
}

Arguments

{ HASH | ORDER } GROUP

Spécifie que les agrégations décrites par GROUP BY la requête ou DISTINCT la clause doivent utiliser le hachage ou l’ordre.

{ MERGE | HASH | CONCAT } UNION

Spécifie que toutes les UNION opérations sont exécutées en fusionnant, en hachage ou en concaténant des UNION jeux. Si plusieurs UNION indicateurs sont spécifiés, l’optimiseur de requête sélectionne la stratégie la moins coûteuse à partir de ces indicateurs spécifiés.

{ LOOP | MERGE | HASH } JOIN

Spécifie que toutes les opérations de jointure sont effectuées par LOOP JOIN, MERGE JOINou HASH JOIN dans l’ensemble de 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 de la même requête pour une paire de FROM tables spécifique, cet indicateur de jointure 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 de la paire de tables peut seulement restreindre la sélection des méthodes de jointure autorisées dans l'indicateur de requête. Pour plus d’informations, consultez indicateurs de jointure.

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.

Remarque

La vue indexée reste condensée s’il existe une référence directe à la vue dans la partie de SELECT 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 NOEXPANDde requête, consultez Utilisation de NOEXPAND.

L’indicateur affecte uniquement les vues dans la partie des SELECT instructions, y compris ces vues dans INSERT, UPDATE, MERGEet les DELETE instructions.

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. L’utilisation FORCE ORDER n’affecte pas le comportement d’inversion de rôle possible de l’optimiseur de requête.

Remarque

Dans une MERGE instruction, la table source est accessible avant la table cible comme ordre de jointure par défaut, sauf si la WHEN SOURCE NOT MATCHED clause est spécifiée. La spécification FORCE ORDER conserve 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 pousse pas vers le stockage Azure.

{ FORCE | DISABLE } SCALEOUTEXECUTION

Force ou désactive l’exécution d’un scale-out des requêtes PolyBase qui utilisent des tables externes dans Clusters Big Data SQL Server 2019. 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 pour les tables temporaires et les rend identiques aux seuils des tables permanentes. Le seuil de recompilation estimé démarre une recompilation automatique pour la requête lorsque le nombre estimé de modifications de colonne indexées est apporté à une table en exécutant l’une des instructions suivantes :

UPDATE
DELETE
MERGE
INSERT

La spécification KEEP PLAN garantit qu’une requête n’est pas recompilée aussi fréquemment lorsqu’il existe plusieurs mises à jour d’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. La spécification KEEPFIXED PLAN garantit qu’une requête recompile uniquement si le schéma des tables sous-jacentes change, ou s’il 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 de l’allocation de mémoire dans PERCENT 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 de l’allocation de mémoire dans PERCENT 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 MAXDOP de requête peut dépasser la valeur configurée avec sp_configure. Si MAXDOP elle dépasse la valeur configurée avec Resource Governor, la Moteur de base de données utilise la valeur Resource GovernorMAXDOP, décrite dans ALTER WORKLOAD GROUP. Toutes les règles sémantiques utilisées avec l’option de configuration max degree of parallelism sont applicables lorsque vous utilisez l’indicateur MAXDOP de requête. Pour plus d’informations, consultez Configurer l’option de configuration du serveur max degree of parallelism.

Avertissement

Si MAXDOP la valeur est égale à 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. nombre est un entier positif 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 le nombre spécifié ou par défaut pour MAXRECURSION la limite est atteint pendant l’exécution de la requête, la requête se termine et une erreur retourne.

À cause de cette erreur, tous les effets de l'instruction sont annulés. Si l’instruction est une SELECT instruction, des résultats partiels ou aucun résultat peuvent être retournés. Il se peut que parmi les résultats partiels éventuellement retournés ne figurent pas toutes les lignes des niveaux de récursivité supérieurs au niveau de récursivité maximal spécifié.

Pour plus d’informations, consultez WITH common_table_expression.

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 de spool peut diminuer 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 OPTIMIZE FOR requête.
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 à attribuer @variable_name à utiliser avec l’indicateur de OPTIMIZE FOR requête. 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 lorsque vous créez OPTIMIZE FOR 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élection moyenne du prédicat sur toutes les valeurs de colonne, au lieu d’utiliser la valeur du paramètre 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 s’applique à la requête lors de sa compilation.

Important

L’indicateur PARAMETERIZATION de requête ne peut être spécifié qu’à l’intérieur d’un repère de plan pour remplacer le paramètre actuel de l’option PARAMETERIZATION de base de données SET . 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 de paramétrer 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 uniquement prise en charge 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 aucune erreur ou 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 QUERYTRACEON indicateur pour chaque numéro d’indicateur de trace différent.

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é dans le cache lorsque la même requête s’exécute sans l’indicateur RECOMPILE . Sans spécifier RECOMPILE, le Moteur de base de données met en cache les plans de requête et les réutilise. Lorsque les plans de requête sont compilés, l’indicateur RECOMPILE de requête utilise les valeurs actuelles de toutes les 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 une alternative utile à la création d’une procédure stockée. RECOMPILE utilise la WITH RECOMPILE clause quand seul un sous-ensemble de requêtes à l’intérieur de la procédure stockée, au lieu de la procédure stockée entière, doit être recompilé. Pour plus d’informations, consultez Recompiler une procédure stockée. RECOMPILE est également utile lorsque vous créez des repères de plan.

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. Lors du traitement de la requête, les tables et les opérateurs intermédiaires peuvent avoir à stocker et à traiter des lignes plus grandes que n'importe quelle ligne d'entrée. Elles peuvent être parfois si grandes que l'opérateur particulier ne peut pas les traiter. 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. Le Moteur de base de données permet de définir des lignes d’une taille maximale potentielle que le Moteur de base de données n’est pas en mesure de 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 un ou plusieurs conseils supplémentaires au processeur de requêtes. Les indicateurs supplémentaires sont spécifiés avec un nom d’indicateur entre guillemets simples.

Conseil

Les noms d’indicateur respectent la casse.

Les noms d’indicateur suivants sont pris en charge :

Indice	Description
`'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'`	Fait en sorte que SQL Server génère un plan de requête à l’aide de l’hypothèse d’endiguement simple au lieu de l’hypothèse d’isolement de base par défaut pour les jointures, sous le modèle d’estimation de cardinalité de l’optimiseur de requête de SQL Server 2014 (12.x) et versions ultérieures. 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 lorsqu’il est utilisé avec le modèle d’estimation de cardinalité de SQL Server 2012 (11.x) et les versions antérieures, et a un effet similaire lorsque l’indicateur de trace 9471 est utilisé avec le modèle d’estimation de cardinalité de SQL Server 2014 (12.x) et les 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 cardinalité de SQL Server 2012 (11.x) et des versions antérieures, et équivalent à l’indicateur de trace 9472 lorsqu’il est utilisé avec le modèle d’estimation de cardinalité de SQL Server 2014 (12.x) et les 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 cardinalité de SQL Server 2014 (12.x) et des 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 2017 (14.x) et versions ultérieures, 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 2017 (14.x) et versions ultérieures, 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 2019 (15.x) et versions ultérieures, 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 2017 (14.x) et versions ultérieures, 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. Cet indicateur s’applique également aux tris explicites et aux tris par lots.
`'DISABLE_OPTIMIZER_ROWGOAL'`	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 : - `TOP` - `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 au paramètre `PARAMETER_SNIFFING = OFF`de configuration de l’indicateur de trace 4136 ou de la base de données.
`'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 2019 (15.x) et versions ultérieures, 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 2019 (15.x) et versions ultérieures, 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 2019 (15.x) et versions ultérieures, 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 de la requête pour tenir compte de la valeur maximale ou minimale réelle de cette 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 au paramètre `QUERY_OPTIMIZER_HOTFIXES = ON`de configuration de l’indicateur de trace 4199 ou de la base de données.
`'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. Utilisez cet indicateur pour remplacer le paramètre `LEGACY_CARDINALITY_ESTIMATION = ON` de configuration délimitée par la base de données ou 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 au paramètre `LEGACY_CARDINALITY_ESTIMATION = ON`de configuration de l’indicateur de trace 9481 ou de la base de données.
`'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. Pour obtenir la liste des valeurs actuellement prises en charge pour n, consultez sys.dm_exec_valid_use_hints. S’applique à : SQL Server 2017 (14.x) CU 10 et versions ultérieures, et Azure SQL Database
`'QUERY_PLAN_PROFILE'` ²	Permet un profilage léger pour la requête. Lorsqu’une requête qui contient ce nouvel indicateur se termine, un nouvel événement étendu, `query_plan_profile`est déclenché. Cet événement étendu expose les statistiques d’exécution et le code XML du plan d’exécution réel similaire à l’événement `query_post_execution_showplan` étendu, mais uniquement pour les requêtes qui contiennent le nouvel indicateur. S’applique à : SQL Server 2016 (13.x) SP 2 CU 3, SQL Server 2017 (14.x) CU 11 et versions ultérieures

¹ L’indicateur QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n ne remplace pas le paramètre d’estimation de cardinalité par défaut ou hérité, si vous le forcez par le biais d’une configuration délimitée par la base de données, d’un indicateur de trace ou d’un autre indicateur de requête tel que 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 plus d’informations, consultez Le choix du développeur : modèle d’exécution de requête indicateur.

² Si vous activez la collecte de l’événement query_post_execution_showplan étendu, l’infrastructure de profilage standard est ajoutée à 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énements query_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énement query_plan_profile étendu, cela active uniquement l’infrastructure de profilage légère pour une requête exécutée avec le query_plan_profile serveur 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 plus d’informations sur le profilage léger, consultez l’infrastructure de profilage des requêtes.

La liste de tous les noms pris en charge USE HINT peut être interrogée à l’aide de la vue de gestion dynamique sys.dm_exec_valid_use_hints.

Important

Certains USE HINT indicateurs 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 de requête (USE HINT) est toujours prioritaire. Si un USE HINT autre indicateur de requête est en conflit ou si un indicateur de trace est activé au niveau de la requête (par QUERYTRACEONexemple), SQL Server génère une erreur lors de la tentative d’exécution de 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. USE PLAN ne peut pas être spécifié avec INSERT, UPDATE, MERGEou DELETE instructions.

Le plan d’exécution résultant forcé par cette fonctionnalité est identique ou similaire au plan forcé. É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 perte de performances peut être importante. 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.
Lorsqu’un alias n’est pas utilisé, exposed_object_name correspond exactement à la table ou à la vue référencée dans la FROM clause. 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 INDEX indicateur de table lorsque vous ne pouvez pas modifier la requête d’origine. Voir l’exemple J.

<table_hint>

Indicateur de table à appliquer à la table ou à la vue qui correspond à exposed_object_name comme indicateur de requête. Pour obtenir une description de ces indicateurs, consultez indicateurs de table.

Attention

La spécification FORCESEEK avec des paramètres limite le nombre de plans qui peuvent être pris en compte par l’optimiseur de requête plus que lors de FORCESEEK la spécification sans paramètres. Cela peut provoquer une erreur « Impossible de générer le plan » dans davantage de cas.

FOR TIMESTAMP AS OF « point_in_time »

S'applique à : Entrepôt dans Microsoft Fabric

Utilisez la syntaxe TIMESTAMP de la clause OPTION pour interroger les données telles qu’elles existaient dans le passé, une partie de la fonctionnalité de voyage dans Synapse Data Warehouse dans Microsoft Fabric.

Spécifiez le point_in_time dans le format yyyy-MM-ddTHH:mm:ss[.fff] pour retourner des données telles qu’elles apparaissent à ce moment-là. Le fuseau horaire est toujours au format UTC. Utilisez la syntaxe CONVERT pour le format datetime nécessaire avec le style 126.

L’indicateur TIMESTAMP AS OF ne peut être spécifié qu’une seule fois à l’aide de la clause OPTION. Pour plus d’informations et de limitations, consultez Données de requête telles qu’elles existaient dans le passé.

Notes

Les indicateurs de requête ne peuvent pas être spécifiés dans une INSERT instruction, sauf lorsqu’une SELECT clause est utilisée à l’intérieur de l’instruction.

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 TABLE HINT clause 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 ou FORCESEEK l’indicateur INDEXde table en tant qu’indicateur de requête uniquement dans le contexte d’un repère de plan. FORCESCAN 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 de compiler et est optimisé. Pour les requêtes ad hoc, utilisez la TABLE HINT clause 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 en tant qu’indicateur de requête, les INDEXindicateurs de table et FORCESEEK les FORCESCANindicateurs de table sont valides pour les objets suivants :

Tables
Les vues
Vues indexées
Expressions de table courantes (l’indicateur doit être spécifié dans l’instruction dont le SELECT jeu de résultats remplit l’expression de table commune)
Vues de gestion dynamique
Sous-requêtes nommées

Vous pouvez spécifier INDEX, FORCESCANet FORCESEEK les indicateurs de table en tant qu’indicateurs de requête pour une requête qui n’a pas d’indicateurs de table existants. Vous pouvez également les utiliser pour remplacer les indicateurs existants ou FORCESEEK FORCESCANexistants INDEXdans la requête, respectivement.

Indicateurs de table autres que INDEX, FORCESCANet FORCESEEK sont interdits en tant qu’indicateurs de requête, sauf si la requête a déjà une WITH clause spécifiant l’indicateur de table. Dans ce cas, il faut également spécifier un indicateur correspondant comme indicateur de requête. Spécifiez l’indicateur correspondant en tant qu’indicateur de requête à l’aide TABLE HINT de la OPTION clause. Cette spécification préserve la sémantique de la requête. Par exemple, si la requête contient l’indicateur NOLOCKde table, la OPTION clause du 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 l’exécution MERGE JOIN de 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 formé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 elle 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 et FAST les HASH GROUP indicateurs de requête. 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 vous appliquez l’indicateur INDEX sur une table qui utilise un alias, la TABLE HINT clause doit également spécifier le même alias que le nom de l’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 FORCESEEK table. La TABLE HINT clause doit également spécifier le même nom en deux parties que le nom de l’objet exposé. Spécifiez le nom lorsque vous appliquez l’indicateur INDEX sur 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 à un 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 utiliser l’indicateur TABLE HINT . Vous pouvez utiliser l’indicateur sans spécifier d’indicateur pour remplacer le comportement de l’indicateur INDEX de table que vous spécifiez dans la FROM clause 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 est affectant sémantiquement et INDEX, qui n’affecte pas la sémantique. Pour conserver la sémantique de la requête, l’indicateur NOLOCK est spécifié dans la OPTIONS clause du repère de plan. Outre l’indicateur NOLOCK , spécifiez les INDEX indicateurs et FORCESEEK les indicateurs et remplacez l’indicateur non sémantique INDEX dans la requête pendant la compilation et l’optimisation des instructions. 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. Autoriser l’optimiseur à choisir en spécifiant l’indicateur NOLOCK dans la OPTIONS clause. En effet, cet indicateur affecte la sémantique. Ensuite, spécifiez le TABLE HINT mot clé avec uniquement une référence de table et aucun INDEX indicateur. 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 et USE HINT les RECOMPILE indicateurs de requête. 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 QUERYTRACEON indicateurs de requête. 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 appliquer une taille maximale d’allocation de mémoire dans PERCENT la limite de mémoire configurée à query_id 39, identifiée dans 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 1et le comportement de l’optimiseur de requête SQL Server 2012 (11.x) :

EXEC sys.sp_query_store_set_hints @query_id= 39,
    @query_hints = N'OPTION(RECOMPILE, MAXDOP 1, USE HINT(''QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_110''))';

O. Interroger des données à partir d’un point dans le temps