Indicateurs de requête (Transact-SQL)

2025-06-11

S’applique à :point de terminaison d’analytique SQL Azure SQL Database Azure SQL Database Azure SQL Dans Microsoft Fabric Warehouse dans Microsoft FabricSQL Database dans Microsoft FabricSQL Database

Les indicateurs de requête spécifient que les indicateurs indiqués sont utilisés dans l’étendue d’une requête. Ils affectent tous les opérateurs de l’instruction. Si UNION est impliqué dans la requête principale, seule la dernière requête impliquant une opération de UNION peut avoir la clause OPTION. Les indicateurs de requête sont spécifiés dans le cadre de la clause OPTION. L’erreur 8622 se produit si un ou plusieurs indicateurs de requête entraînent la génération d’un plan valide par l’optimiseur de requête.

Avertissement

Étant donné que l’optimiseur de requête SQL Server sélectionne généralement le meilleur plan d’exécution pour une requête, nous vous recommandons uniquement d’utiliser des indicateurs comme dernier recours pour les développeurs expérimentés et les administrateurs de base de données.

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

Les arguments

{ HASH | ORDER } GROUP

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

En règle générale, un algorithme basé sur un hachage peut améliorer les performances des requêtes qui impliquent des ensembles de regroupements volumineux ou complexes.
En règle générale, un algorithme basé sur le tri peut améliorer les performances des requêtes qui impliquent des ensembles de regroupements petits ou simples.

{ MERGE | HASH | CONCAT } UNION

Spécifie que toutes les opérations UNION sont exécutées en fusionnant, en hachage ou en concaténant des jeux UNION. Si plusieurs UNION indicateur 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.

En règle générale, une opération d’algorithme basée sur la fusion peut améliorer les performances des requêtes qui impliquent des entrées triées.
En règle générale, un algorithme basé sur un hachage peut améliorer les performances des requêtes qui impliquent des entrées non triées ou volumineuses.
En règle générale, un algorithme basé sur la concaténation peut améliorer les performances des requêtes qui impliquent des entrées distinctes ou petites.

{ 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 vous spécifiez plusieurs indicateurs de jointure, l’optimiseur sélectionne la stratégie de jointure la moins coûteuse parmi celles 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, cet indicateur de jointure est prioritaire dans la jointure des deux tables. Toutefois, les indicateurs de requête doivent toujours ê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.

DISABLE_OPTIMIZED_PLAN_FORCING

S’applique à : SQL Server (à compter de SQL Server 2022 (16.x))

Désactive plan optimisé forçant 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é.

DÉVELOPPER LES VUES

Spécifie les vues indexées sont développées. Spécifie également que l’optimiseur de requête ne considère pas d’affichage indexé comme remplacement d’une partie de requête. Une vue est développée lorsque la définition de la vue remplace le nom de la vue dans le texte de la requête.

Cet indicateur de requête interdit pratiquement l’utilisation directe des vues indexées et des index sur les 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 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 Using NOEXPAND.

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

FAST integer_value

Spécifie que la requête est optimisée pour une récupération rapide du premier integer_value nombre de lignes. Ce résultat est un entier non négatif. Une fois que le premier integer_value nombre de lignes est retourné, la requête continue l’exécution et produit son jeu de résultats complet.

FORCER L’ORDRE

Spécifie que l’ordre de jointure indiqué par la syntaxe de requête est conservé lors de l’optimisation de la requête. L’utilisation de FORCE ORDER n’affecte pas le comportement d’inversion de rôle possible de l’optimiseur de requête.

FORCE ORDER conserve l’ordre de jointure spécifié dans la requête, ce qui peut améliorer les performances ou la cohérence des requêtes qui impliquent des conditions de jointure ou des indicateurs complexes.

Remarque

Dans une instruction MERGE, la table source est accessible avant la table cible comme ordre de jointure par défaut, sauf si la clause WHEN SOURCE NOT MATCHED est spécifiée. La spécification de FORCE ORDER conserve ce comportement par défaut.

{ FORCE | DISABLE } EXTERNALPUSHDOWN

Forcez ou désactivez le pushdown du calcul des expressions éligibles dans Hadoop. S’applique uniquement aux requêtes utilisant PolyBase. Ne pousse pas vers le 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 clusters Big Data SQL Server 2019. Cet indicateur est uniquement respecté 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.

CONSERVER LE 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 de 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 des modifications apportées aux statistiques. En spécifiant KEEPFIXED PLAN assurez-vous qu’une requête recompile uniquement si le schéma des tables sous-jacentes change ou si sp_recompile s’exécute sur ces tables.

IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX

S’applique à: SQL Server (à partir de SQL Server 2012 (11.x)).

Empêche la requête d’utiliser un index columnstore optimisé en mémoire non cluster. 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 de limite de mémoire configurée. La requête est garantie de ne pas dépasser cette limite si la requête s’exécute dans un pool de ressources défini par l’utilisateur. Dans ce cas, si la requête n’a pas 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 (valeur par défaut), elle obtient au minimum la mémoire requise pour s’exécuter. La limite réelle peut être inférieure si le paramètre 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 de limite de mémoire configurée. La requête est garantie d’obtenir MAX(required memory, min grant), car au moins la mémoire requise est nécessaire pour 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 (Ko)) 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 (à partir de SQL Server 2008 (10.0.x)) et d’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 Resource Governor, décrite dans ALTER WORKLOAD GROUP. Toutes les règles sémantiques utilisées avec l'degré maximal de parallélisme option de configuration sont applicables lorsque vous utilisez l’indicateur de requête MAXDOP. Pour plus d’informations, consultez Configuration du serveur : degré maximal de parallélisme.

Avertissement

Si MAXDOP est défini sur zéro, le serveur choisit le degré maximal de parallélisme.

MAXRECURSION <integer_value>

Spécifie le nombre maximal de récursivités autorisées 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 limite est atteint pendant l’exécution de la requête, la requête se termine et une erreur est retournée.

En raison de cette erreur, tous les effets de l’instruction sont restauré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.

NO_PERFORMANCE_SPOOL

s’applique à: SQL Server (à partir de SQL Server 2016 (13.x)) et d’Azure SQL Database.

Empêche l’ajout d’un opérateur de spoul à des plans de requête (à l’exception des plans lorsque le spoul est requis pour garantir la sémantique de mise à jour valide). L’opérateur depool peut réduire les performances dans certains scénarios. Par exemple, le spool utilise tempdb, et tempdb contention peut se produire s’il existe de nombreuses requêtes simultanées s’exécutant avec les opérations de pool.

OPTIMIZE FOR ( @variable_name { UNKNOWN | = <literal_constant> } [ , ... n ] )

Indique à l’optimiseur de requête d’utiliser une valeur particulière pour une variable locale lorsque la requête est compilée et optimisée. 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 au lieu de la valeur initiale pour déterminer la valeur d’une variable locale lors de l’optimisation des requêtes.
literal_constant

Valeur de constante littérale à affecter @variable_name à utiliser avec l’indicateur de requête OPTIMIZE FOR. literal_constant est utilisé uniquement pendant l’optimisation des requêtes, 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 la forme d’une constante littérale. Le type de données de literal_constant doit être implicitement convertible en type de données qui @variable_name références 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 lorsque vous créez des repères de plan. Pour plus d’informations, consultez Recompiler une procédure stockée.

OPTIMISER POUR INCONNU

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 le literal_constant spécifié pour une valeur spécifique. L’optimiseur de requête utilise UNKNOWN pour le reste des valeurs de variable. Les valeurs sont utilisées uniquement pendant l’optimisation des requêtes, et non pendant l’exécution de la requête.

PARAMETERIZATION { SIMPLE | FORCÉ }

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 de requête PARAMETERIZATION 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 base de données SET. Elle ne peut pas être spécifiée directement dans une requête.

Pour plus d’informations, consultez Spécifier le comportement de paramétrage des requêtes à l’aide des 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êteset Paramétrage simple dans le Guide de l’architecture de traitement des requêtes.

<INTEGER_VALUE> QUERYTRACEON

Cette option vous permet d’activer un indicateur de trace affectant le plan uniquement pendant la compilation à requête unique. Comme d’autres options au niveau de la requête, vous pouvez l’utiliser avec des repères de plan pour faire correspondre le texte d’une requête exécutée à partir de n’importe quelle session et appliquer automatiquement un indicateur de trace affectant le plan lorsque cette requête est compilée. L’option QUERYTRACEON n’est prise en charge que pour les indicateurs de trace de l’optimiseur de requête. Pour plus d’informations, consultez 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 un indicateur 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 différent.

RECOMPILER

Indique au moteur de base de données SQL Server de générer un nouveau plan temporaire pour la requête et d’ignorer immédiatement ce plan une fois la requête terminée. 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 de 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 de requête RECOMPILE 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 passées à tous les paramètres.

RECOMPILE est une alternative utile à la création d’une procédure stockée. RECOMPILE utilise la clause WITH RECOMPILE 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.

PLAN ROBUSTE

Force l’optimiseur de requête à essayer un plan qui fonctionne pour la taille maximale de ligne potentielle, éventuellement au détriment 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. Si les lignes sont aussi larges, le moteur de base de données génère une erreur pendant 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 ce plan n’est pas possible, l’optimiseur de requête retourne une erreur au lieu de différer la détection d’erreurs pour 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 qui ont une taille potentielle maximale au-delà de la capacité du moteur de base de données à les traiter. En règle générale, malgré la taille maximale potentielle, une application stocke les lignes qui ont des tailles réelles dans les limites que le moteur de base de données peut traiter. Si le moteur de base de données traverse une ligne trop longue, une erreur d’exécution est retournée.

USE HINT ( 'hint_name' )

S’applique à : SQL Server (à partir de SQL Server 2016 (13.x) SP1), Azure SQL Database et Azure SQL Managed Instance.

Fournit un ou plusieurs conseils supplémentaires au processeur de requêtes. Les indicateurs supplémentaires sont spécifiés avec le nom de l’indicateur entre guillemets simples.

Conseil / Astuce

Les noms d’indicateurs ne respectent pas la casse.

Les noms d’indicateurs suivants sont pris en charge :

Indice	Descriptif
`'ABORT_QUERY_EXECUTION'`	Bloque l’exécution des requêtes. Destiné à être utilisé comme indicateur du Magasin des requêtes pour permettre aux administrateurs de bloquer l’exécution future de requêtes problématiques connues, par exemple les requêtes non essentielles ayant un impact sur les charges de travail d’application. Pour plus d’informations, consultez Bloquer l’exécution future de requêtes problématiques. S’applique à : Azure SQL Database et SQL Server 2025 (17.x) Préversion. Cet indicateur est en préversion.
`'ASSUME_FIXED_MIN_SELECTIVITY_FOR_REGEXP'`	Le modèle d’estimation de cardinalité pour REGEXP_LIKE fournit des valeurs de sélection par défaut. Utilisez cet indicateur si l’estimation par défaut est trop élevée. Elle définit la sélectivité sur une valeur de sélectivité inférieure fixe. S’applique à : SQL Server 2025 (17.x) Préversion et versions ultérieures, et Azure SQL Database
`'ASSUME_FIXED_MAX_SELECTIVITY_FOR_REGEXP'`	Le modèle d’estimation de cardinalité pour REGEXP_LIKE fournit des valeurs de sélection par défaut. Utilisez cet indicateur si l’estimation par défaut est trop faible. Elle définit la sélectivité sur une valeur de sélectivité supérieure fixe. S’applique à : SQL Server 2025 (17.x) Préversion et versions ultérieures, et Azure SQL Database
`'ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS'`	Génère un plan de requête à l’aide de l’hypothèse Simple Containment au lieu de l’hypothèse d’endiguement de base par défaut pour les jointures, sous l’optimiseur de requête modèle d’estimation de cardinalité modèle de SQL Server 2014 (12.x) et versions ultérieures. Ce nom d’indicateur équivaut à indicateur de trace 9476.
`'ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES'`	Génère un plan à l’aide de la sélection minimale lors de l’estimation des prédicats AND pour les filtres afin de tenir compte de la corrélation complète. Ce nom d’indicateur équivaut à 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 indicateur de trace 9471 est utilisé avec le modèle d’estimation de cardinalité de SQL Server 2014 (12.x) et versions ultérieures.
`'ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES'`	Génère un plan à l’aide de la sélection maximale lors de l’estimation des prédicats AND pour les filtres afin de tenir compte de l’indépendance totale. 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 équivaut à indicateur de trace 9472 lorsqu’il est utilisé avec le modèle d’estimation de cardinalité de SQL Server 2014 (12.x) et versions ultérieures. s’applique à: Azure SQL Database
`'ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES'`	Génère un plan utilisant la plupart des sélections minimales lors de l’estimation des prédicats AND pour les filtres afin de tenir 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 commentaires d’octroi de mémoire en mode batch. Pour plus d’informations, consultez commentaires sur l’octroi 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 des variables 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 à plusieurs instructions. Pour plus d’informations, consultez exécution entrelacée pour les fonctions table à plusieurs instructions. S’applique à : SQL Server 2017 (14.x) et versions ultérieures, et Azure SQL Database
`'DISABLE_OPTIMIZED_HALLOWEEN_PROTECTION'`	Désactive la protection d’Halloween optimisée. Pour plus d’informations, consultez La protection d’Halloween optimisée S’applique à : SQL Server 2025 (17.x) Preview
`'DISABLE_OPTIMIZED_NESTED_LOOP'`	Indique au processeur de requêtes de ne pas utiliser d’opération de tri (tri par lot) pour les jointures de boucle imbriquées optimisées lors de la génération d’un plan de requête. Ce nom d’indicateur équivaut à indicateur de trace 2340. Cet indicateur s’applique également aux tris explicites et aux tris par lots.
`'DISABLE_OPTIMIZER_ROWGOAL'`	Provoque la génération d’un plan qui n’utilise pas de modifications d’objectif de ligne avec des requêtes qui contiennent ces mots clés : - `TOP` - `OPTION (FAST N)` - `IN` - `EXISTS` Ce nom d’indicateur équivaut à 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 avec un ou plusieurs paramètres. Cette instruction rend le plan de requête indépendant de la valeur du paramètre qui a été utilisée lors de la compilation de la requête. Ce nom d’indicateur équivaut à indicateur de trace 4136 ou configuration étendue à la base de données paramètre `PARAMETER_SNIFFING = OFF`.
`'DISABLE_ROW_MODE_MEMORY_GRANT_FEEDBACK'`	Désactive les commentaires d’octroi de mémoire en mode ligne. Pour plus d’informations, consultez commentaires sur l’octroi 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’inlining UDF scalaire. Pour plus d’informations, consultez d’inlining UDF Scalar. 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 les statistiques rapides générées automatiquement (modification de l’histogramme) pour toute colonne d’index de début pour laquelle 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 à indicateur de trace 4139.
`'ENABLE_OPTIMIZED_HALLOWEEN_PROTECTION'`	Active la protection d’Halloween optimisée. Pour plus d’informations, consultez La protection d’Halloween optimisée. S’applique à : SQL Server 2025 (17.x) Preview
`'ENABLE_QUERY_OPTIMIZER_HOTFIXES'`	Active les correctifs logiciels de l’optimiseur de requête (modifications publiées dans les mises à jour cumulatives SQL Server et les Service Packs). Ce nom d’indicateur équivaut à indicateur de trace 4199 ou configuration étendue à la base de données paramètre `QUERY_OPTIMIZER_HOTFIXES = ON`.
`'FORCE_DEFAULT_CARDINALITY_ESTIMATION'`	Force l’optimiseur de requête à utiliser modèle d’estimation de cardinalité qui correspond au niveau de compatibilité de la base de données actuel. Utilisez cet indicateur pour remplacer paramètre de configuration délimitée à la base de données`LEGACY_CARDINALITY_ESTIMATION = ON` ou indicateur de trace 9481.
`'FORCE_LEGACY_CARDINALITY_ESTIMATION'`	Force l’optimiseur de requête à utiliser modèle d’estimation de cardinalité de SQL Server 2012 (11.x) et des versions antérieures. Ce nom d’indicateur équivaut à indicateur de trace 9481 ou configuration étendue à la base de données paramètre `LEGACY_CARDINALITY_ESTIMATION = ON`.
`'QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_n'` ¹	Force le comportement de l’optimiseur de requête au niveau d’une requête. Ce comportement se produit comme si la requête a été compilée avec le niveau de compatibilité de base de données n, où n est un niveau de compatibilité de base de données 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'` ²	Active le 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 étendu `query_post_execution_showplan`, 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
`'DISABLE_RESULT_SET_CACHE'`	Désactive la mise en cache du jeu de résultats (préversion) pour une exécution spécifique d’une requête, si le cache du jeu de résultats est activé pour l’élément actuellement connecté. Cela signifie qu’il ne génère pas de nouveau cache de jeu de résultats ni ne tire parti du cache de jeu de résultats existant (le cas échéant). Cela peut être utile dans les scénarios de débogage ou de test A/B. Pour plus d’informations, consultez Mise en cache du jeu de résultats. S’applique à : Microsoft Fabric

¹ L’indicateur de 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 de la configuration étendue à la base de données, de l’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. Elle n’affecte pas d’autres fonctionnalités de SQL Server qui peuvent dépendre du niveau de compatibilité base de données, telles que la disponibilité de certaines fonctionnalités de base de données. Pour plus d’informations, consultez Choix du développeur : indicateur du modèle d’exécution de requête.

² Si vous activez la collecte de l’événement étendu query_post_execution_showplan, 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 de query_thread_profile événement étendu 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 étendu query_plan_profile, cela active uniquement l’infrastructure de profilage légère pour une requête exécutée avec le query_plan_profile 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 Infrastructure de profilage des requêtes.

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

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 de requête (USE HINT) est toujours prioritaire. Si un USE HINT est en conflit avec un autre indicateur de requête ou si un indicateur de trace est activé au niveau de la requête (par exemple, par QUERYTRACEON), 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.

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 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 à la 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 :

Lorsqu’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 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 est le même nom en deux parties.

Lorsque vous spécifiez exposed_object_name sans également spécifier d’indicateur de table, tous les index que vous spécifiez dans la requête dans le cadre d’un indicateur de table pour 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. Consultez 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.

Avertissement

La spécification de 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 la spécification de FORCESEEK sans paramètres. Cela peut entraîner une erreur « Impossible de générer un plan » dans d’autres cas.

POUR TIMESTAMP AS OF 'point_in_time'

s’applique à: Entrepôt dans Microsoft Fabric

Utilisez la syntaxe TIMESTAMP dans 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 la point_in_time au 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 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é.

FORCE [ SINGLE NODE | DISTRIBUTED ] PLAN

s’applique à: Entrepôt dans Microsoft Fabric

Permet à l’utilisateur de choisir s’il faut forcer un plan de nœud unique ou un plan distribué pour l’exécution de la requête.

Remarques

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

Les indicateurs de requête peuvent être spécifiés uniquement dans la requête de niveau supérieur, et non dans les sous-requêtes. Lorsqu’un indicateur de table est spécifié en tant qu’indicateur de requête, l’indicateur peut être spécifié dans la requête de niveau supérieur 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 des indicateurs de table en tant qu’indicateurs de requête

Nous vous recommandons d’utiliser l’indicateur de table INDEX, FORCESCANou FORCESEEK comme indicateur de requête uniquement dans le contexte d’un guide de plan de . Les repères de plan sont utiles lorsque vous ne pouvez pas modifier la requête d’origine, par exemple, car 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 clause TABLE HINT uniquement lors du test des instructions de repère de plan. Pour toutes les autres requêtes ad hoc, nous vous recommandons de spécifier ces indicateurs uniquement en tant qu’indicateurs de table.

Lorsqu’ils sont spécifiés en tant qu’indicateur de requête, les INDEX, les FORCESCANet les indicateurs de table FORCESEEK sont valides pour les objets suivants :

Tableaux
Les vues
Vues indexées
Expressions de table courantes (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 (DMV)
Sous-requêtes nommées

Vous pouvez spécifier INDEX, FORCESCANet FORCESEEK indicateurs de table comme indicateurs de requête pour une requête qui n’a aucun indicateur de table existant. Vous pouvez également les utiliser pour remplacer les INDEXexistants, les FORCESCANou les indicateurs de FORCESEEK dans la requête, respectivement.

Les 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 clause WITH spécifiant l’indicateur de table. Dans ce cas, un indicateur correspondant doit également être spécifié en tant qu’indicateur de requête. Spécifiez l’indicateur correspondant comme indicateur de requête à l’aide de TABLE HINT dans la clause OPTION. Cette spécification conserve 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. Consultez exemple deK .

Spécifier des indicateurs avec des indicateurs du Magasin des requêtes

Vous pouvez appliquer des conseils sur les requêtes identifiées via le Magasin des requêtes sans apporter de modifications de code à l’aide des indicateurs magasin de requêtes fonctionnalité. Utilisez la procédure stockée sys.sp_query_store_set_hints pour appliquer un indicateur à une requête. Voir l’exemple N.

Prise en charge des indicateurs de requête dans Fabric Data Warehouse

Microsoft Fabric Data Warehouse prend en charge un sous-ensemble d’indicateurs de requête :

HASH GROUP
ORDER GROUP
MERGE UNION
HASH UNION
CONCAT UNION
FORCE ORDER
USE HINT
- ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES
- ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES
- ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES
- ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS

Ces indicateurs de requête sont exclusifs à Microsoft Fabric Data Warehouse :

FORCE SINGLE NODE PLAN, , FORCE DISTRIBUTED PLANDISABLE_RESULT_SET_CACHE

Exemples

Un. Utiliser MERGE JOIN

L’exemple suivant spécifie que MERGE JOIN exécute l’opération de 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

Chapitre C. Utiliser MAXRECURSION

MAXRECURSION pouvez ê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 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 de INDEX. Le premier exemple spécifie un index unique. Le deuxième exemple spécifie plusieurs index pour une référence de table unique. Dans les deux exemples, étant donné que vous appliquez l’indicateur INDEX sur une table qui utilise un alias, la clause TABLE HINT 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 table FORCESEEK. La clause TABLE HINT 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

Je. 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 remplacer un indicateur de table existant

L’exemple suivant montre comment utiliser l’indicateur de TABLE HINT. Vous pouvez utiliser l’indicateur sans spécifier d’indicateur pour remplacer le comportement de l’indicateur de table INDEX que vous spécifiez 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 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 clause OPTIONS du repère de plan. En plus de l’indicateur NOLOCK, spécifiez les indicateurs INDEX et FORCESEEK et remplacez l’indicateur de INDEX non sémantique affectant 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 montre une autre méthode pour préserver la sémantique de la requête et autoriser l’optimiseur à 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. Vous spécifiez l’indicateur, car il affecte sémantiquement. Ensuite, spécifiez le mot clé TABLE HINT avec uniquement une référence de table et aucun indicateur de 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. Use 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 logiciels affectant le plan contrôlés par l’indicateur de trace 4199 pour une requête particulière à l’aide de 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é d’indicateurs du Magasin des requêtes fournit une méthode facile à utiliser pour mettre en forme des plans de requête sans modifier le code de l’application.

Tout d’abord, identifiez la requête qui a déjà été exécutée dans les vues de 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 forcer 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 de limite de mémoire configurée à query_id 39, identifiée 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 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''))';

L’exemple suivant bloque la requête avec le query_id 39 à partir de l’exécution ultérieure en appliquant l’indicateur ABORT_QUERY_EXECUTION . L’indicateur est en préversion.

EXEC sys.sp_query_store_set_hints @query_id = 39,
    @query_hints = N'OPTION (USE HINT (''ABORT_QUERY_EXECUTION''))';

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

s’applique à: Entrepôt dans Microsoft Fabric

Utilisez la syntaxe TIMESTAMP dans la clause OPTION pour interroger les données telles qu’elles existaient dans le passé, dans Synapse Data Warehouse dans Microsoft Fabric. L’exemple de requête suivant retourne des données telles qu’elles apparaissent le 13 mars 2024 à 17:39:35.28 UTC. Le fuseau horaire est toujours au format UTC.

SELECT OrderDateKey, SUM(SalesAmount) AS TotalSales
FROM FactInternetSales
GROUP BY OrderDateKey
ORDER BY OrderDateKey
OPTION (FOR TIMESTAMP AS OF '2024-03-13T19:39:35.28');--March 13, 2024 at 7:39:35.28 PM UTC

P. La requête force un nœud unique ou une requête distribuée

s’applique à: Entrepôt dans Microsoft Fabric

Pour forcer une requête dans Fabric Data Warehouse à utiliser un nœud unique, utilisez force [ SINGLE NODE | INDICATEUR DE PLAN DISTRIBUÉ .

SELECT OrderDateKey, SalesAmount
FROM FactInternetSales
OPTION (FORCE SINGLE NODE PLAN);

Pour forcer une requête dans Fabric Data Warehouse à utiliser une requête distribuée :

SELECT OrderDateKey, SalesAmount
FROM FactInternetSales
OPTION (FORCE DISTRIBUTED PLAN);

Q. Désactiver une requête de création ou d’application du cache du jeu de résultats (préversion)

S’applique à : Microsoft Fabric

Utilisez 'DISABLE_RESULT_SET_CACHE' le cache hint_name du jeu de résultats pour une exécution particulière d’une requête. Pour plus d’informations, consultez Mise en cache du jeu de résultats.

SELECT OrderDateKey, SUM(SalesAmount) AS TotalSales
FROM FactInternetSales
GROUP BY OrderDateKey
ORDER BY OrderDateKey
OPTION (USE HINT ('DISABLE_RESULT_SET_CACHE'));

Partager via

Indicateurs de requête (Transact-SQL)

Syntaxe

Les arguments

{ HASH | ORDER } GROUP

{ MERGE | HASH | CONCAT } UNION

{ LOOP | MERGE | HASH } JOIN

DISABLE_OPTIMIZED_PLAN_FORCING

DÉVELOPPER LES VUES

FAST integer_value

FORCER L’ORDRE

{ FORCE | DISABLE } EXTERNALPUSHDOWN

{ FORCE | DISABLE } SCALEOUTEXECUTION

CONSERVER LE PLAN

KEEPFIXED PLAN

IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX

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 ] )

OPTIMISER POUR INCONNU

PARAMETERIZATION { SIMPLE | FORCÉ }

<INTEGER_VALUE> QUERYTRACEON

RECOMPILER

PLAN ROBUSTE

USE HINT ( 'hint_name' )

USE PLAN N’xml_plan'

TABLE HINT ( exposed_object_name [ , <table_hint> [ [ , ] ... n ] )

POUR TIMESTAMP AS OF 'point_in_time'

FORCE [ SINGLE NODE | DISTRIBUTED ] PLAN

Remarques

Spécifier des indicateurs de table en tant qu’indicateurs de requête

Spécifier des indicateurs avec des indicateurs du Magasin des requêtes

Prise en charge des indicateurs de requête dans Fabric Data Warehouse

Exemples

Un. Utiliser MERGE JOIN

B. Utiliser OPTIMIZE FOR

Chapitre C. Utiliser MAXRECURSION

D. Utiliser MERGE UNION

E. Utiliser HASH GROUP et FAST

F. Utiliser MAXDOP

G. Utiliser INDEX

H. Utiliser FORCESEEK

Je. Utiliser plusieurs indicateurs de table

J. Utiliser TABLE HINT pour remplacer un indicateur de table existant

K. Spécifier des indicateurs de table affectant la sémantique

L. Use USE HINT

m. Utiliser QUERYTRACEON HINT

N. Utiliser les indicateurs du Magasin des requêtes

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

P. La requête force un nœud unique ou une requête distribuée

Q. Désactiver une requête de création ou d’application du cache du jeu de résultats (préversion)

Contenu connexe

Commentaires

Ressources supplémentaires