Caractéristiques du traitement de requêtes intelligent en détail

Article
07/12/2024

S’applique à : SQL Server base de données Azure SQL Azure SQL Managed Instance

Cet article contient des descriptions détaillées des différentes fonctionnalités de traitement des requêtes intelligentes (IQP) des notes de publication et plus de détails. La famille de fonctionnalités de traitement de requêtes intelligent inclut des fonctionnalités qui améliorent les performances des charges de travail existantes avec un minimum d’effort d’implémentation à entreprendre.

Vous pouvez faire en sorte que les charges de travail soient automatiquement éligibles au traitement de requêtes intelligent en activant le niveau de compatibilité applicable pour la base de données. Vous pouvez définir cette option à l’aide de Transact-SQL. Par exemple, pour définir le niveau de compatibilité d’une base de données sur SQL Server 2022 (16.x) :

ALTER DATABASE [WideWorldImportersDW] SET COMPATIBILITY_LEVEL = 160;

Toutes les fonctionnalités IQP sont disponibles dans Azure SQL Managed Instance et base de données Azure SQL, parfois en fonction du mode de compatibilité de chaque base de données. Pour plus d’informations sur les modifications introduites avec les nouvelles versions, consultez :

Jointures adaptatives en mode batch

S’applique à : SQL Server (à partir de SQL Server 2017 (14.x)) et base de données Azure SQL

La fonctionnalité des jointures adaptatives en mode batch, permet de choisir de différer une méthode Jointure hachée ou jointure de boucles imbriquées tant que la première entrée n’a pas été analysée, à l’aide d’un plan de mise en cache unique. L’opérateur de jointure adaptative définit un seuil qui sert à déterminer le moment où il faut basculer vers un plan de boucles imbriquées. Votre plan peut, par conséquent, passer dynamiquement à une meilleure stratégie de jointure pendant l’exécution.

Pour plus d’informations, notamment sur la désactivation des jointures adaptatives sans modifier le niveau de compatibilité, consultez Comprendre les jointures adaptatives.

Exécution entrelacée pour les fonctions table à instructions multiples (MSTVF)

S’applique à : SQL Server (à partir de SQL Server 2017 (14.x)) et base de données Azure SQL

Une fonction table à plusieurs instructions (MSTVF) est un type de fonction définie par l’utilisateur qui peut accepter des paramètres, exécuter plusieurs instructions T-SQL et RETURN une table.

L’exécution entrelacée entraîne des problèmes de performance des charges de travail qui sont liés aux estimations de cardinalité fixes associées aux MSTVF. Avec l’exécution entrelacée, le nombre réel de lignes de la fonction est utilisé pour prendre des décisions de plan de requête en aval plus avisées.

Les fonctions table à instructions multiples ont une estimation de cardinalité fixe égale à 100 à compter de SQL Server 2014 (12.x), et égale à 1 pour les versions antérieures de SQL Server.

L’exécution entrelacée change la limite unidirectionnelle entre les phases d’exécution et d’optimisation pour l’exécution d’une seule requête, et permet d’adapter les plans selon les estimations de cardinalité révisées. Pendant l’optimisation, si le moteur de base de données rencontre un candidat pour l’exécution entrelacée, c’est-à-dire des fonctions table à instructions multiples (MSTVF), l’optimisation se met en pause, le moteur exécute la sous-arborescence applicable, capture des estimations de cardinalité précises, puis l’optimisation reprend pour les opérations en aval.

L’image suivante illustre une sortie de Statistiques des requêtes actives, un sous-ensemble d’un plan d’exécution global qui montre l’impact des estimations de cardinalité fixes des MSTVF.

Vous pouvez comparer le flux de lignes réel et les lignes estimées. Il y a trois zones notables dans le plan (le flux va de droite à gauche) :

L’analyse de table MSTVF utilise une estimation fixe de 100 lignes. Dans cet exemple, toutefois, l’analyse de table présente un flux de 527 597 lignes, comme indiqué dans les statistiques des requêtes actives par 527597 sur 100 (nombre réel sur nombre estimé). L’estimation fixe est donc considérablement biaisée.
Pour l’opération de boucles imbriquées, seules 100 lignes sont supposées être retournées par le côté extérieur de la jointure. Étant donné le nombre élevé de lignes retournées par la MSTVF, vous avez tout intérêt à utiliser un autre algorithme de jointure.
Pour l’opération de correspondance de hachage, notez le petit symbole d’avertissement qui indique dans ce cas un dépassement de capacité sur le disque.

Comparez le plan précédent au plan réel généré avec l’exécution entrelacée :

Notez que l’analyse de table MSTVF reflète maintenant une estimation de cardinalité précise. Notez également la réorganisation de cette analyse de table et des autres opérations.
Concernant les algorithmes de jointure, nous sommes passés d’une opération de boucles imbriquées à une opération de correspondance de hachage, qui est plus adaptée étant donné le nombre important de lignes concernées.
Notez également que nous n’avons plus d’avertissements de dépassement de capacité, car nous allouons davantage de mémoire en fonction du nombre de lignes réel de l’analyse de table MSTVF.

Instructions éligibles pour l’exécution entrelacée

Les instructions de référence MSTVF dans l’exécution entrelacée doivent être en lecture seule et ne pas faire partie d’une opération de modification de données. De plus, les MSTVF ne sont pas éligibles pour l’exécution entrelacée si elles n’utilisent pas de constantes d’exécution.

Avantages de l’exécution entrelacée

En règle générale, plus le décalage est important entre le nombre de lignes réel et estimé, associé au nombre d’opérations de plan en aval, plus l’impact sur les performances est élevé.

En général, l’exécution entrelacée bénéficie aux requêtes dans les situations suivantes :

Il y a un décalage important entre le nombre réel et le nombre estimé de lignes pour le jeu de résultats intermédiaire (dans ce cas, la MSTVF).
En outre, la requête globale est sensible à un changement de taille du résultat intermédiaire. Cela se produit généralement quand une arborescence complexe englobe la sous-arborescence dans le plan de requête. Une simple instruction SELECT * d’une MSTVF ne tire aucun bénéfice de l’exécution entrelacée.

Surcharge de l’exécution entrelacée

La surcharge doit être minime, voire nulle. Les MSTVF ont déjà été matérialisées avant l’introduction de l’exécution entrelacée, mais cette fois nous autorisons une optimisation différée et nous tirons parti de l’estimation de cardinalité de l’ensemble des lignes matérialisées. Comme c’est le cas avec n’importe quel changement affectant le plan, certains plans peuvent changer à un point tel que l’amélioration de la cardinalité de la sous-arborescence entraîne un plan complètement inadapté pour la requête globale. Pour atténuer cet effet, vous pouvez rétablir le niveau de compatibilité ou utiliser le Magasin des requêtes pour forcer l’utilisation de la version non régressée du plan.

Exécution entrelacée et exécutions consécutives

Une fois qu’un plan d’exécution entrelacée est mis en cache, le plan avec les estimations révisées issues de la première exécution est utilisé pour les exécutions consécutives sans nouvelle instanciation de l’exécution entrelacée.

Suivre l’activité d’exécution entrelacée

Vous pouvez voir les attributs d’utilisation dans le plan d’exécution de requête réel :

Attribut de plan d'exécution	Description
ContainsInterleavedExecutionCandidates	S’applique au nœud QueryPlan. Quand la valeur est true, cela signifie que le plan contient des candidats pour l’exécution entrelacée.
IsInterleavedExecuted	Attribut de l’élément RuntimeInformation sous le RelOp pour le nœud TVF. Quand la valeur est true, cela signifie que l’opération a été matérialisée dans le cadre d’une opération d’exécution entrelacée.

Vous pouvez également suivre les occurrences d’exécution entrelacée via les événements étendus suivants :

Événement xEvent	Description
`interleaved_exec_status`	Cet événement se déclenche quand l’exécution entrelacée se produit.
`interleaved_exec_stats_update`	Cet événement décrit les estimations de cardinalité mises à jour par l’exécution entrelacée.
`Interleaved_exec_disabled_reason`	Cet événement se déclenche quand une requête avec un candidat possible pour l’exécution entrelacée n’obtient pas l’exécution entrelacée.

Une requête doit être exécutée pour permettre à l’exécution entrelacée de réviser les estimations de cardinalité MSTVF. Toutefois, le plan d’exécution estimé montre toujours s’il y a des candidats pour l’exécution entrelacée via l’attribut de plan d’exécution de requêtes ContainsInterleavedExecutionCandidates.

Mise en cache de l’exécution entrelacée

Si un plan est effacé ou supprimé du cache, à l’exécution de la requête c’est une nouvelle compilation qui utilise l’exécution entrelacée. Une instruction qui utilise OPTION (RECOMPILE) crée un plan à l’aide de l’exécution entrelacée et ne le met pas en cache.

Interopérabilité de l’exécution entrelacée et du Magasin des requêtes

L’utilisation des plans qui utilisent l’exécution entrelacée peut être forcée. Le plan est la version dont les estimations de cardinalité ont été corrigées en fonction de l’exécution initiale.

Désactiver l’exécution entrelacée sans modifier le niveau de compatibilité

L’exécution entrelacée peut être désactivée dans l’étendue de la base de données ou de l’instruction tout en maintenant le niveau de compatibilité de base de données 140 et au-delà. Pour désactiver l’exécution entrelacée pour toutes les exécutions de requête en provenance de la base de données, exécutez ce qui suit dans le contexte de la base de données applicable :

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = ON;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = OFF;

Quand il est activé, ce paramètre apparaît comme étant activé dans sys.database_scoped_configurations. Pour réactiver l’exécution entrelacée pour toutes les exécutions de requête en provenance de la base de données, exécutez ce qui suit dans le contexte de la base de données applicable :

-- SQL Server 2017
ALTER DATABASE SCOPED CONFIGURATION SET DISABLE_INTERLEAVED_EXECUTION_TVF = OFF;

-- Starting with SQL Server 2019, and in Azure SQL Database
ALTER DATABASE SCOPED CONFIGURATION SET INTERLEAVED_EXECUTION_TVF = ON;

Vous pouvez aussi désactiver l’exécution entrelacée pour une requête spécifique en désignant DISABLE_INTERLEAVED_EXECUTION_TVF en tant qu’indicateur de requête USE HINT. Par exemple :

SELECT [fo].[Order Key], [fo].[Quantity], [foo].[OutlierEventQuantity]
FROM [Fact].[Order] AS [fo]
INNER JOIN [Fact].[WhatIfOutlierEventQuantity]('Mild Recession',
                            '1-01-2013',
                            '10-15-2014') AS [foo] ON [fo].[Order Key] = [foo].[Order Key]
                            AND [fo].[City Key] = [foo].[City Key]
                            AND [fo].[Customer Key] = [foo].[Customer Key]
                            AND [fo].[Stock Item Key] = [foo].[Stock Item Key]
                            AND [fo].[Order Date Key] = [foo].[Order Date Key]
                            AND [fo].[Picked Date Key] = [foo].[Picked Date Key]
                            AND [fo].[Salesperson Key] = [foo].[Salesperson Key]
                            AND [fo].[Picker Key] = [foo].[Picker Key]
OPTION (USE HINT('DISABLE_INTERLEAVED_EXECUTION_TVF'));

Un indicateur de requête USE HINT est prioritaire par rapport à une configuration incluse dans l’étendue d’une base de données ou à un paramètre d’indicateur de trace.

Incorporation (inlining) des fonctions UDF scalaires

S’applique à : SQL Server (à partir de SQL Server 2019 (15.x)) et base de données Azure SQL

La fonctionnalité d’incorporation des fonctions UDF scalaires transforme automatiquement les fonctions UDF scalaires en expressions relationnelles. Elle les incorpore dans la requête SQL appelante. Cette transformation améliore les performances des charges de travail qui tirent parti des fonctions UDF scalaires. La fonctionnalité d’incorporation des fonctions UDF scalaires facilite l’optimisation basée sur le coût des opérations à l’intérieur des fonctions UDF. Les résultats sont des plans efficaces, axés sur les ensembles et parallèles au lieu de plans d’exécution inefficaces, itératifs, en série. Cette fonctionnalité est activée par défaut sous le niveau de compatibilité de base de données 150 ou plus.

Pour plus d’informations, consultez Incorporation des fonctions UDF scalaires.

Compilation différée de variable de table

S’applique à : SQL Server (à partir de SQL Server 2019 (15.x)) et base de données Azure SQL

La compilation différée de variable de table améliore la qualité du plan et les performances globales pour les requêtes faisant référence à des variables de table. Pendant l’optimisation et la compilation initiale du plan, cette fonctionnalité propage les estimations de cardinalité basées sur le nombre réel de lignes de la variable de table. Le nombre exact de lignes sera ensuite utilisé pour optimiser les opérations de plan en aval.

Avec la compilation différée de la variable de table, la compilation d’une instruction qui fait référence à une variable de table est différée jusqu'à la première exécution réelle de l’instruction. Ce comportement de compilation différée est identique à celui des tables temporaires. Cette modification entraîne l’utilisation de la cardinalité réelle au lieu de l’estimation d’origine sur une ligne.

Pour permettre la compilation différée des variables de table, définissez le niveau de compatibilité de la base de données à 150 ou plus pour la base de données à laquelle vous êtes connecté durant l’exécution de la requête.

La compilation différée de variables de table ne modifie aucune autre caractéristique des variables de table. Par exemple, cette fonctionnalité n’ajoute pas de statistiques de colonnes aux variables de table.

La compilation différée de variables de table n’augmente pas la fréquence des recompilations. Au lieu de cela, elle se positionne là où la compilation initiale se produit. Le plan mis en cache obtenu est généré en fonction du nombre de lignes de variable de table dans la compilation différée initiale. Le plan mis en cache est réutilisé par des requêtes consécutives. Et ce, jusqu’à ce que le plan soit supprimé ou recompilé.

Le nombre de lignes de variable de table utilisé pour la compilation du plan initial représente une valeur type très différente d’une estimation du nombre de lignes fixe. S’il est différent, les opérations en aval en bénéficieront. Si le nombre de lignes de variable de table varie de manière significative entre les exécutions, il est possible que cette fonctionnalité n’améliore pas les performances.

Désactiver la compilation différée de variables de table sans changer le niveau de compatibilité

Désactivez la compilation différée des variables de table au niveau de la base de données ou de l’instruction, tout en maintenant un niveau de compatibilité de la base de données supérieur ou égal à 150. Pour désactiver la compilation différée des variables de table dans toutes les exécutions de requête provenant de la base de données, exécutez l’exemple suivant dans le contexte de la base de données applicable :

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Pour réactiver la compilation différée des variables de table dans toutes les exécutions de requête provenant de la base de données, exécutez l’exemple suivant dans le contexte de la base de données applicable :

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

Vous pouvez également désactiver la compilation différée des variables de table pour une requête spécifique en désignant DISABLE_DEFERRED_COMPILATION_TV comme un indicateur de requête USE HINT. Par exemple :

DECLARE @LINEITEMS TABLE 
    (L_OrderKey INT NOT NULL,
     L_Quantity INT NOT NULL
    );

INSERT @LINEITEMS
SELECT L_OrderKey, L_Quantity
FROM dbo.lineitem
WHERE L_Quantity = 5;

SELECT O_OrderKey,
    O_CustKey,
    O_OrderStatus,
    L_QUANTITY
FROM    
    ORDERS,
    @LINEITEMS
WHERE    O_ORDERKEY    =    L_ORDERKEY
    AND O_OrderStatus = 'O'
OPTION (USE HINT('DISABLE_DEFERRED_COMPILATION_TV'));

Optimisation du plan de sensibilité des paramètres

S’applique à : SQL Server 2022 (16.x)base de données Azure SQL Azure SQL Managed Instance

L’optimisation du plan de sensibilité des paramètres fait partie de la famille de fonctionnalités de traitement intelligent des requêtes. Elle traite le scénario dans lequel un seul plan mis en cache pour une requête paramétrable n’est pas optimal pour toutes les valeurs de paramètre entrantes possibles. C’est le cas avec les distributions de données non uniformes.

Pour plus d’informations sur l’optimisation PSP, consultez Optimisation du plan de confidentialité des paramètres.
Pour plus d’informations sur la paramétrisation et la sensibilité des paramètres, consultez Sensibilité des paramètres et Réutilisation des paramètres et du plan d’exécution.

Traitement des requêtes approximatif

Le traitement des requêtes approximatif est une nouvelle famille de fonctionnalités. Il fournit des agrégations dans de vastes jeux de données où la réactivité est plus importante que la précision absolue. Un exemple est le calcul d’un COUNT(DISTINCT()) sur 10 milliards de lignes pour l’affichage sur un tableau de bord. Dans ce cas, la précision absolue n’est pas importante, mais la réactivité est essentielle.

Comptage approximatif des valeurs distinctes

S’applique à : SQL Server (à partir de SQL Server 2019 (15.x)) et base de données Azure SQL

La nouvelle fonction d’agrégation APPROX_COUNT_DISTINCT retourne le nombre approximatif de valeurs non null uniques dans un groupe.

Cette fonctionnalité est disponible à partir de SQL Server 2019 (15.x), quel que soit le niveau de compatibilité.

Pour plus d’informations, consultez APPROX_COUNT_DISTINCT (Transact-SQL).

Centile approximatif

S’applique à : SQL Server (à partir de SQL Server 2022 (16.x)) et Azure SQL Database

Ces fonctions d’agrégation calculent rapidement des centiles pour un grand jeu de données avec des limites d’erreur acceptables basées sur le classement pour une prise de décision rapide à l’aide de fonctions d’agrégation de centiles approximatives.

Pour plus d’informations, consultez APPROX_PERCENTILE_DISC (Transact-SQL) et APPROX_PERCENTILE_CONT (Transact-SQL)

Mode Batch sur rowstore

S’applique à : SQL Server (à partir de SQL Server 2019 (15.x)) et base de données Azure SQL

Le mode batch sur rowstore permet l’exécution en mode batch des charges de travail analytiques sans avoir besoin d’index columnstore. Cette fonctionnalité prend en charge les filtres bitmap et l’exécution du mode batch des segments de mémoire sur disque et des index B-tree. Le mode batch sur rowstore permet de prendre en charge tous les opérateurs existants compatibles avec le mode batch.

Remarque

De manière générale, la documentation utilise le terme B-tree en référence aux index. Dans les index rowstore, le moteur de base de données implémente une structure B+. Cela ne s’applique pas aux index columnstore ou aux tables à mémoire optimisée. Pour plus d’informations, consultez le Guide de conception et d’architecture d’index SQL Server et Azure SQL.

Vue d’ensemble de l’exécution en mode batch

SQL Server 2012 (11.x) a introduit une nouvelle fonctionnalité permettant d’accélérer les charges de travail analytiques : les index columnstore. Les cas d’utilisation et les performances des index columnstore ont été améliorés dans chaque version suivante de SQL Server. La création d’index columnstore sur des tables peut améliorer les performances des charges de travail analytiques. Toutefois, il existe deux jeux de technologies connexes mais distincts :

Les index ColumnStore permettent aux requêtes analytiques d’accéder uniquement aux données dans les colonnes nécessaires. La compression de page au format columnstore est aussi plus efficace que la compression dans des index rowstore traditionnels.
Avec le traitement en mode batch, les opérateurs de requête traitent les données plus efficacement. Ils travaillent sur un lot de lignes au lieu d’une ligne à la fois. De nombreuses autres améliorations d’évolutivité sont liées au traitement en mode Batch. Pour plus d’informations sur le mode batch, consultez Modes d’exécution.

Les deux ensembles de fonctionnalités interagissent pour améliorer les E/S (entrées/sorties) et l’utilisation du processeur :

En utilisant des index columnstore, une plus grande quantité de vos données s’intègre dans la mémoire. Cela réduit la charge de travail d’E/S.
Le traitement en mode Batch utilise plus efficacement le processeur.

Dès que possible, les deux technologies tirent parti l’une de l’autre. Par exemple, les agrégats en mode Batch peuvent être évalués dans le cadre d’une analyse d’index columnstore. Les données columnstore compressées sont également traitées à l’aide de l’encodage de la longueur d’exécution de manière beaucoup plus efficace avec les jointures en mode batch et les agrégats en mode batch.

Il est toutefois important de comprendre que les deux fonctionnalités sont indépendantes :

Vous pouvez obtenir des plans en mode ligne qui utilisent des index columnstore.
Vous pouvez obtenir des plans en mode batch qui utilisent uniquement des index rowstore.

Vous obtenez généralement les meilleurs résultats lorsque vous utilisez les deux fonctionnalités ensemble. Avant SQL Server 2019 (15.x), l’optimiseur de requête SQL Server ne prenait en compte le traitement en mode batch que pour les requêtes impliquant au moins une table avec un index columnstore.

Les index columnstore ne sont peut-être pas appropriés pour certaines applications. Une application peut utiliser une autre fonctionnalité qui n’est pas pris en charge avec des index columnstore. Par exemple, les modifications sur place ne sont pas compatibles avec la compression columnstore. Les déclencheurs ne sont donc pas pris en charge sur les tables avec des index columnstore en cluster. Plus important encore, les index columnstore ajoutent une surcharge aux instructions DELETE et UPDATE.

Pour certaines charges de travail transactionnelles-analytiques hybrides, la surcharge d’une charge de travail transactionnelle l’emporte sur les avantages liés à l’utilisation des index columnstore. De tels scénarios peuvent bénéficier d’une utilisation améliorée du processeur via un traitement en mode batch uniquement. C’est la raison pour laquelle la fonctionnalité Mode batch sur rowstore prend en compte le mode batch pour toutes les requêtes, quel que soit le type d’index concerné.

Charges de travail pouvant tirer parti du mode Batch sur rowstore

Les charges de travail suivantes peuvent tirer parti du mode Batch sur rowstore :

Une partie importante de la charge de travail se compose de requêtes analytiques. En règle générale, ces requêtes utilisent des opérateurs tels que des jointures ou des agrégats qui traitent des centaines de milliers de lignes ou plus.
La charge de travail est liée à l’UC. Si le goulot d’étranglement se situe au niveau des E/S, il est toujours recommandé d’envisager l’utilisation d’un index columnstore, si possible.
La création d’un index columnstore ajoute trop de surcharge à la partie transactionnelle de votre charge de travail. Ou bien, la création d’un index columnstore est impossible, car votre application dépend d’une fonctionnalité qui n’est pas encore prise en charge avec les index columnstore.

Remarque

Le mode Batch sur rowstore ne peut aider qu’en réduisant la consommation de l’UC. Si votre goulot d’étranglement est lié aux E/S et si les données ne sont pas déjà mises en cache (cache « à froid »), le mode batch sur rowstore n’améliore pas le temps écoulé des requêtes. De même, si la mémoire de la machine est insuffisante pour mettre en cache toutes les données, une amélioration des performances est peu probable.

Ce qui change avec le mode Batch sur rowstore

Le mode Batch sur rowstore nécessite une base de données au niveau de compatibilité 150.

Même si une requête n’accède à aucune table avec des index columnstore, le processeur de requêtes détermine l’utilisation ou non du mode batch à l’aide d’informations heuristiques. Les données heuristiques sont constituées de ces vérifications :

Une vérification initiale des tailles de la table, des opérateurs utilisés et des cardinalités estimées dans la requête d’entrée.
Des points de contrôle supplémentaires, lorsque l’optimiseur détecte des plans nouveaux et à moindre coût pour la requête. Si ces autres plans n’utilisent pas le mode Batch de manière significative, l’optimiseur cesse d’explorer les alternatives du mode Batch.

Si le mode Batch sur rowstore est utilisé, vous voyez le mode d’exécution réel en tant que mode Batch dans le plan de requête. L’opérateur d’analyse utilise le mode Batch pour les segments de mémoire sur disque et les index B-tree. Cette analyse en mode Batch peut évaluer les filtres de bitmap du mode Batch. Vous pouvez également voir d’autres opérateurs en mode Batch dans le plan. Par exemple, les jonctions de hachage, les agrégats basés sur le hachage, les tris, les agrégats de fenêtre, les filtres, la concaténation et les opérateurs scalaires de calcul.

Notes

Les plans de requête n’utilisent pas toujours le mode Batch. L’optimiseur de requête peut décider que le mode Batch n’est pas utile pour la requête.

L’espace de recherche de l’optimiseur de requête change. Par conséquent, si vous obtenez un plan en mode ligne, il peut être différent du plan que vous obtenez dans un niveau de compatibilité inférieur. Et si vous obtenez un plan en mode Batch, il peut être différent du plan que vous obtenez avec un index columstore.

Les plans peuvent également changer pour les requêtes qui combinent des index columnstore et rowstore, en raison de la nouvelle analyse rowstore du mode Batch.

Voici les limitations actuelles pour la nouvelle analyse du mode Batch sur rowstore :

Elle n’intervient pas pour les tables OLTP en mémoire, ou pour tout index autre que des segments de mémoire sur disque et des arborescences B-tree.
Elle n’intervient pas non plus si une colonne LOB est récupérée ou filtrée. Cette limitation inclut les jeux de colonnes éparses et les colonnes XML.

Il existe des requêtes pour lesquelles le mode Batch n’est pas utilisé même avec des index columnstore. Les requêtes qui impliquent des curseurs en sont des exemples. Ces mêmes exclusions s’étendent également au mode Batch sur rowstore.

Configurer le mode Batch sur rowstore

La configuration délimitée à la base de données BATCH_MODE_ON_ROWSTORE est ACTIVÉE par défaut.

Vous pouvez désactiver le mode Batch sur rowstore sans changer le niveau de compatibilité de la base de données :

-- Disabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = OFF;

-- Enabling batch mode on rowstore
ALTER DATABASE SCOPED CONFIGURATION SET BATCH_MODE_ON_ROWSTORE = ON;

Vous pouvez désactiver le mode Batch sur rowstore via la configuration au niveau de la base de données. Mais vous pouvez toujours remplacer le paramètre au niveau de la requête à l’aide de l’indicateur de requête ALLOW_BATCH_MODE. L’exemple suivant active le mode Batch sur rowstore même avec la fonctionnalité désactivée via la configuration limitée à la base de données :

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('ALLOW_BATCH_MODE'));

Vous pouvez aussi désactiver le mode Batch sur rowstore pour une requête spécifique à l’aide de l’indicateur de requête DISALLOW_BATCH_MODE. Voir l’exemple suivant :

SELECT [Tax Rate], [Lineage Key], [Salesperson Key], SUM(Quantity) AS SUM_QTY, SUM([Unit Price]) AS SUM_BASE_PRICE, COUNT(*) AS COUNT_ORDER
FROM Fact.OrderHistoryExtended
WHERE [Order Date Key]<=DATEADD(dd, -73, '2015-11-13')
GROUP BY [Tax Rate], [Lineage Key], [Salesperson Key]
ORDER BY [Tax Rate], [Lineage Key], [Salesperson Key]
OPTION(RECOMPILE, USE HINT('DISALLOW_BATCH_MODE'));

Fonctionnalités de rétroaction de traitement de requêtes

Les fonctionnalités de retour d’expérience sur le traitement des requêtes font partie de la famille de fonctionnalités de traitement des requêtes intelligent.

Le retour sur le traitement des requêtes est un processus par lequel le processeur de requêtes dans SQL Server, base de données Azure SQL et Azure SQL Managed Instance utilise des données historiques sur l’exécution d’une requête pour décider si la requête peut recevoir de l’aide d’une ou plusieurs modifications apportées à la façon dont elle est compilée et exécutée. Les données de performances sont collectées dans le magasin de requêtes, avec différentes suggestions pour améliorer l’exécution des requêtes. En cas de réussite, nous persistons ces modifications sur le disque en mémoire et/ou dans le magasin de requêtes pour une utilisation ultérieure. Si les suggestions ne produisent pas d’amélioration suffisante, elles sont ignorées et la requête continue à s’exécuter sans ce retour.

Pour plus d’informations sur les fonctionnalités de retour du traitement des requêtes disponibles dans différentes versions de SQL Server, ou dans base de données Azure SQL ou Azure SQL Managed Instance, consultez Traitement intelligent des requêtes dans les bases de données SQL ou les articles suivants pour chaque fonctionnalité de commentaires.

Rétroaction d’allocation de mémoire

Le retour sur l’octroi de mémoire a été introduit par vagues au cours des dernières versions majeures de SQL Server.

Retour d’allocation de mémoire en mode batch

Pour plus d’informations sur le retour sur l’allocation de mémoire en mode Batch, consultez Retour sur l’octroi de mémoire en mode Batch.

Rétroaction d’allocation de mémoire en mode ligne

Pour plus d’informations sur le retour sur l’allocation de mémoire en mode Ligne, consultez Retour sur l’octroi de mémoire en mode Ligne.

Rétroaction d’allocation de mémoire en mode centile et persistance

Pour plus d’informations sur le retour sur l’allocation de mémoire en mode centile et de persistance, consultez Retour sur l’allocation de mémoire en mode centile et de persistance.

Commentaires sur le degré de parallélisme (DOP)

Pour plus d’informations, consultez Commentaires sur le degré de parallélisme (DOP).

Retour d'expérience sur l'estimation de la cardinalité (CE)

Pour plus d’informations sur le retour sur CE, visitez Retour sur l’estimation de cardinalité (CE).

Forçage de plan optimisé avec le Magasin des requêtes

Pour plus d’informations sur le forçage de plan optimisé avec le Magasin des requêtes, visitez Forçage de plan optimisé avec le Magasin des requêtes.

Partager via

Caractéristiques du traitement de requêtes intelligent en détail

Jointures adaptatives en mode batch

Exécution entrelacée pour les fonctions table à instructions multiples (MSTVF)

Instructions éligibles pour l’exécution entrelacée

Avantages de l’exécution entrelacée

Surcharge de l’exécution entrelacée

Exécution entrelacée et exécutions consécutives

Suivre l’activité d’exécution entrelacée

Mise en cache de l’exécution entrelacée

Interopérabilité de l’exécution entrelacée et du Magasin des requêtes

Désactiver l’exécution entrelacée sans modifier le niveau de compatibilité

Incorporation (inlining) des fonctions UDF scalaires

Compilation différée de variable de table

Désactiver la compilation différée de variables de table sans changer le niveau de compatibilité

Optimisation du plan de sensibilité des paramètres

Traitement des requêtes approximatif

Comptage approximatif des valeurs distinctes

Centile approximatif

Mode Batch sur rowstore

Vue d’ensemble de l’exécution en mode batch

Charges de travail pouvant tirer parti du mode Batch sur rowstore

Ce qui change avec le mode Batch sur rowstore

Notes

Configurer le mode Batch sur rowstore

Fonctionnalités de rétroaction de traitement de requêtes

Rétroaction d’allocation de mémoire

Retour d’allocation de mémoire en mode batch

Rétroaction d’allocation de mémoire en mode ligne

Rétroaction d’allocation de mémoire en mode centile et persistance

Commentaires sur le degré de parallélisme (DOP)

Retour d'expérience sur l'estimation de la cardinalité (CE)

Forçage de plan optimisé avec le Magasin des requêtes

Commentaires

Ressources supplémentaires

Partager via

Caractéristiques du traitement de requêtes intelligent en détail

Jointures adaptatives en mode batch

Exécution entrelacée pour les fonctions table à instructions multiples (MSTVF)

Instructions éligibles pour l’exécution entrelacée

Avantages de l’exécution entrelacée

Surcharge de l’exécution entrelacée

Exécution entrelacée et exécutions consécutives

Suivre l’activité d’exécution entrelacée

Mise en cache de l’exécution entrelacée

Interopérabilité de l’exécution entrelacée et du Magasin des requêtes

Désactiver l’exécution entrelacée sans modifier le niveau de compatibilité

Incorporation (inlining) des fonctions UDF scalaires

Compilation différée de variable de table

Désactiver la compilation différée de variables de table sans changer le niveau de compatibilité

Optimisation du plan de sensibilité des paramètres

Traitement des requêtes approximatif

Comptage approximatif des valeurs distinctes

Centile approximatif

Mode Batch sur rowstore

Vue d’ensemble de l’exécution en mode batch

Charges de travail pouvant tirer parti du mode Batch sur rowstore

Ce qui change avec le mode Batch sur rowstore

Notes

Configurer le mode Batch sur rowstore

Fonctionnalités de rétroaction de traitement de requêtes

Rétroaction d’allocation de mémoire

Retour d’allocation de mémoire en mode batch

Rétroaction d’allocation de mémoire en mode ligne

Rétroaction d’allocation de mémoire en mode centile et persistance

Commentaires sur le degré de parallélisme (DOP)

Retour d'expérience sur l'estimation de la cardinalité (CE)

Forçage de plan optimisé avec le Magasin des requêtes

Contenu connexe

Commentaires

Ressources supplémentaires