Funzionalità di elaborazione di query intelligenti in dettaglio.

Si applica a:SQL Serverdatabase SQL di AzureAzure SQL Istanza gestitaDatabase SQL in Microsoft Fabric

Questo articolo contiene descrizioni approfondite di varie funzionalità di Elaborazione di query intelligenti (IQP), note sulla versione e altri dettagli. La famiglia di funzionalità di elaborazione di query intelligenti include funzionalità ad ampio spettro che migliorano le prestazioni di carichi di lavoro esistenti con un impegno minimo per l'implementazione.

È possibile impostare automaticamente i carichi di lavoro come idonei all'elaborazione di query intelligenti abilitando il livello di compatibilità applicabile per il database. Questa opzione è impostabile con Transact-SQL. Ad esempio, per impostare il livello di compatibilità di un database su SQL Server 2022 (16.x):

ALTER DATABASE [WideWorldImportersDW]
    SET COMPATIBILITY_LEVEL = 160;

Per altre informazioni sulle modifiche introdotte con le nuove versioni, vedere:

• Novità di SQL Server 2025
• Novità di SQL Server 2022
• Novità di SQL Server 2019
• Novità di SQL Server 2017

Join adattivi in modalità batch

Si applica a: SQL Server, a partire da SQL Server 2017 (14.x), e database SQL di Azure

La funzionalità di join adattivo in modalità batch consente di rimandare a dopo la scansione del primo input la scelta tra l'esecuzione di un metodo hash join e l'esecuzione di un metodo join a cicli annidati, usando un singolo piano memorizzato nella cache. L'operatore Adaptive Join definisce una soglia che viene utilizzata per stabilire quando passare a un piano Nested Loops. Durante l'esecuzione il piano può pertanto passare a una strategia di join più efficace.

Per altre informazioni, incluso come disabilitare i join adattivi senza modificare il livello di compatibilità, vedere Informazioni sui join adattivi.

Esecuzione intercalata per MSTVF

Si applica a: SQL Server, a partire da SQL Server 2017 (14.x), e database SQL di Azure

Una Funzione con valori di tabella a più istruzioni (MSTVF) è un tipo di funzione definita dall'utente che può accettare parametri, eseguire più istruzioni T-SQL e RETURN una tabella.

L'esecuzione intervallata contribuisce a risolvere i problemi di prestazioni del carico di lavoro dovuti alle stime di cardinalità fisse associate alle funzioni con valori di tabella a più istruzioni (MSTVF). Con l'esecuzione intercalata, i conteggi effettivi delle righe restituiti dalla funzione vengono usati per prendere decisioni più informate nelle fasi successive del piano di query.

Le MSTVF (funzioni con valori di tabella con istruzioni multiple) hanno una stima di cardinalità fissa pari a 100 a partire da SQL Server 2014 (12.x) e pari a 1 nelle versioni precedenti di SQL Server.

L'esecuzione intercalata modifica il confine unidirezionale tra le fasi di ottimizzazione ed esecuzione durante l'esecuzione di una singola query e consente ai piani di adattarsi in base alle stime di cardinalità aggiornate. Durante l'ottimizzazione, se il motore di database rileva un candidato per l'esecuzione intrecciata che utilizza funzioni con valori di tabella con più istruzioni (MSTVF), l'ottimizzazione si interrompe, esegue il sottoalbero applicabile, acquisisce stime di cardinalità accurate e quindi il motore di database riprende l'ottimizzazione per le operazioni successive.

L'immagine seguente mostra un output di Statistiche delle query in tempo reale, un sottoinsieme di un piano di esecuzione complessivo che mostra l'impatto delle stime di cardinalità fisse per le funzioni con valori di tabella a più istruzioni (MSTVF).

È possibile visualizzare il flusso di righe effettivo e le righe stimate. Tre aree del piano sono degne di nota (il flusso va da destra a sinistra):

• L'analisi di tabella MSTVF include una stima fissa pari a 100 righe. In questo esempio, tuttavia, in questa scansione della tabella MSTVF passano 527.597 righe, come si può vedere nelle Live Query Statistics tramite l’indicazione 527597 of 100 di righe effettive rispetto a quelle stimate; quindi la stima fissa è notevolmente imprecisa.
• Per l'operazione Nested Loops, si presume che dal lato esterno del join vengano restituite solo 100 righe. Dato il numero elevato di righe effettivamente restituite da MSTVF, è probabile che sia meglio usare un algoritmo di join diverso.
• Per l'operazione Hash Match, notare il piccolo simbolo di avviso, che in questo caso sta indicando uno spill su disco.

Confrontare il piano precedente con il piano effettivo generato con l'esecuzione intercalata abilitata:

• L'analisi della tabella MSTVF riflette ora una stima accurata della cardinalità. Si noti anche il riordino della scansione di tabella e delle altre operazioni.
• Quanto agli algoritmi di join, siamo passati da un'operazione Nested Loop a un'operazione Hash Match, che è più efficiente dato l'elevato numero di righe coinvolte.
• Si noti anche che non sono più presenti avvisi di spill, poiché viene allocata più memoria in base al numero effettivo di righe provenienti dalla scansione della tabella MSTVF.

Istruzioni idonee all'esecuzione intercalata

Attualmente, le istruzioni che fanno riferimento a MSTVF nell'ambito dell'esecuzione interleaved devono essere di sola lettura e non far parte di un'operazione di modifica dei dati. Inoltre, le MSTVF non sono idonee per l'esecuzione intercalata se non utilizzano costanti di runtime.

Vantaggi dell'esecuzione intercalata

In generale, maggiore è lo scarto tra il numero di righe stimato e il numero reale (associato al numero di operazioni del piano downstream), maggiore è l'impatto sulle prestazioni.

In generale, l'esecuzione intercalata è vantaggiosa per le query in cui:

• Esiste un'asimmetria elevata tra il numero stimato e il numero effettivo di righe per il set di risultati intermedio (in questo caso, MSTVF).

• La query nel suo complesso è sensibile alla variazione delle dimensioni del risultato intermedio. In genere, ciò accade quando nel piano di query è presente un albero complesso sopra il sottoalbero.

  Una base SELECT * di un MSTVF non trae vantaggio dall'esecuzione interleaved.

Sovraccarico dell'esecuzione interlacciata

Il sovraccarico previsto è minimo o nullo. Le funzioni con valori di tabella con istruzioni multiple (MSTVF) venivano già materializzate prima dell'introduzione dell'esecuzione intercalata; la differenza è che ora consentiamo l'ottimizzazione differita e quindi viene utilizzata la stima della cardinalità dell'insieme di righe materializzato. Come per qualsiasi piano che comporti modifiche, alcuni piani potrebbero cambiare in modo tale che, pur con una cardinalità migliore per il sottoalbero, si ottenga un piano peggiore per la query nel suo complesso. La mitigazione può includere il ripristino del livello di compatibilità o l'uso di Query Store per forzare la versione del piano che non ha subito regressioni.

Esecuzioni intervallate ed esecuzioni consecutive

Una volta che un piano di esecuzione intercalata viene memorizzato nella cache, il piano con le stime aggiornate ottenute durante la prima esecuzione viene usato per le esecuzioni successive senza dover creare nuovamente un'istanza dell'esecuzione intercalata.

Monitorare l'attività di esecuzione intercalata

È possibile visualizzare gli attributi di utilizzo nel piano di esecuzione effettivo della query:

È anche possibile monitorare le occorrenze di esecuzioni intercalate tramite i seguenti eventi estesi:

Per consentire all'esecuzione intercalata di rivedere le stime di cardinalità delle MSTVF, è necessario eseguire una query. Tuttavia il piano di esecuzione stimato viene ancora visualizzato quando sono presenti candidati per l'esecuzione interleaved tramite l'attributo showplan ContainsInterleavedExecutionCandidates.

Memorizzazione nella cache dell'esecuzione interlacciata

Se un piano di esecuzione viene cancellato o rimosso dalla cache, al momento dell'esecuzione della query avviene una nuova compilazione che utilizza l'esecuzione intercalata. Un'istruzione che usa OPTION (RECOMPILE) crea un nuovo piano usando l'esecuzione interleaved e non lo memorizza nella cache.

Esecuzione intercalata e interoperabilità con Query Store

È possibile forzare i piani che utilizzano l'esecuzione interlacciata. Il piano è la versione che presenta stime della cardinalità corrette sulla base dell'esecuzione iniziale.

Disabilitare l'esecuzione intercalata senza modificare il livello di compatibilità

È possibile disabilitare l'esecuzione intercalata a livello di database o di istruzione, pur mantenendo il livello di compatibilità del database pari a 140 o superiore. Per disabilitare l'esecuzione interleaved per tutte le esecuzioni di query provenienti dal database, eseguire l'istruzione seguente all'interno del contesto del database applicabile:

-- 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;

Quando è abilitata, questa impostazione viene visualizzata come abilitata in sys.database_scoped_configurations. Per abilitare nuovamente l'esecuzione interleaved per tutte le esecuzioni di query provenienti dal database, eseguire l'istruzione seguente all'interno del contesto del database applicabile:

-- 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;

È anche possibile disabilitare l'esecuzione interleaved per una query specifica specificando DISABLE_INTERLEAVED_EXECUTION_TVF come hint di query USE HINT. Per esempio:

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

L'hint di query USE HINT ha la precedenza su una configurazione con ambito a livello di database o su un'impostazione del flag di traccia.

Inlining di funzioni scalari definite dall'utente

Si applica a: SQL Server, a partire da SQL Server 2019 (15.x) e database SQL di Azure

L'inlining delle UDF scalari trasforma automaticamente le UDF scalari in espressioni relazionali. Li incorpora nella query SQL che la richiama. Questa trasformazione migliora le prestazioni dei carichi di lavoro che si avvalgono di funzioni scalari definite dall'utente. L'inlining delle funzioni scalari definite dall'utente facilita l'ottimizzazione basata sui costi delle operazioni all'interno delle UDF. I risultati sono efficienti, orientati ai set e paralleli, al contrario dei piani di esecuzione seriale iterativi e poco efficienti. Questa funzionalità è abilitata per impostazione predefinita con livello di compatibilità del database pari a 150 o superiore.

Per ulteriori informazioni, vedere Inlining delle funzioni scalari definite dall'utente.

Compilazione posticipata delle variabili di tabella

Si applica a: SQL Server, a partire da SQL Server 2019 (15.x) e database SQL di Azure

La compilazione posticipata delle variabili di tabella migliora la qualità del piano e le prestazioni generali per le query che fanno riferimento a variabili di tabella. Durante l'ottimizzazione e la compilazione iniziale del piano, questa funzionalità propaga le stime della cardinalità basate sui conteggi effettivi delle righe di variabili di tabella. Queste informazioni esatte sul conteggio delle righe vengono quindi usate per ottimizzare le operazioni del piano downstream.

Con la compilazione posticipata delle variabili di tabella, la compilazione di un'istruzione che fa riferimento a una variabile di tabella viene posticipata fino alla prima esecuzione effettiva dell'istruzione. Questo comportamento della compilazione posticipata è identico a quello delle tabelle temporanee. Questo cambiamento determina l'uso della cardinalità effettiva invece dell'ipotesi originale di una sola riga.

Per abilitare la compilazione posticipata delle variabili di tabella, abilitare il livello di compatibilità database 150 o superiore per il database a cui si è connessi quando si esegue la query.

La compilazione posticipata delle variabili di tabella non modifica altre caratteristiche delle variabili di tabella. Ad esempio, questa funzionalità non aggiunge statistiche di colonna alle variabili di tabella.

La compilazione posticipata delle variabili di tabella non aumenta la frequenza di ricompilazione. Piuttosto, sposta la posizione di esecuzione della compilazione iniziale. Il piano memorizzato nella cache risultante viene generato in base al conteggio delle righe delle variabili di tabella della compilazione posticipata iniziale. Il piano memorizzato nella cache viene riutilizzato per le query consecutive. Viene riutilizzato finché il piano non viene espulso dalla cache o ricompilato.

Un numero di righe delle variabili di tabella usato per la compilazione iniziale del piano, che rappresenta un valore tipico, può differire da un conteggio fisso delle righe. Se è diverso, le operazioni downstream ne beneficiano. Se il conteggio delle righe delle variabili di tabella varia notevolmente tra le esecuzioni, questa funzionalità potrebbe non migliorare le prestazioni.

Disabilitare la compilazione posticipata delle variabili di tabella senza modificare il livello di compatibilità

Disabilitare la compilazione posticipata delle variabili di tabella nell'ambito del database o dell'istruzione mantenendo comunque un livello di compatibilità del database 150 o superiore. Per disabilitare la compilazione posticipata delle variabili di tabella per tutte le esecuzioni di query originate dal database, eseguire questo esempio nel contesto del database applicabile:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = OFF;

Per riabilitare la compilazione posticipata delle variabili di tabella per tutte le esecuzioni di query originate dal database, eseguire questo esempio nel contesto del database applicabile:

ALTER DATABASE SCOPED CONFIGURATION SET DEFERRED_COMPILATION_TV = ON;

È anche possibile disabilitare la compilazione posticipata delle variabili di tabella per una query specifica assegnando DISABLE_DEFERRED_COMPILATION_TV come hint per la query USE HINT. Per esempio:

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'));

Ottimizzazione del piano di sensibilità ai parametri

Si applica a: SQL Server 2022 (16.x) e versioni successive Database SQL di Microsoft AzureIstanza Gestita SQL di Azure

L'ottimizzazione del piano con sensibilità ai parametri (PSP) fa parte della famiglia di funzionalità di elaborazione intelligente delle query. Fa riferimento allo scenario in cui un singolo piano memorizzato nella cache per una query con parametri non risulta ottimale per tutti i possibili valori dei parametri in ingresso. Questa situazione si verifica in caso di distribuzioni di dati non uniformi.

• Per ulteriori informazioni sull'ottimizzazione PSP, vedere Ottimizzazione del piano sensibile ai parametri.
• Per ulteriori informazioni sulla parametrizzazione e sulla sensibilità ai parametri, vedere Sensibilità ai parametri e Parametri e riutilizzo del piano di esecuzione.

Elaborazione approssimativa delle query

L'elaborazione delle query approssimativa è una nuova famiglia di funzionalità, che aggrega set di dati di grandi dimensioni in cui la velocità di risposta è più importante della precisione assoluta. Un esempio è il calcolo di COUNT(DISTINCT()) su 10 miliardi di righe, per la visualizzazione in un dashboard. In questo caso, la precisione assoluta non è importante, ma la velocità di risposta è fondamentale.

Conteggio distinto approssimativo

Si applica a: SQL Server, a partire da SQL Server 2019 (15.x) e database SQL di Azure

La nuova funzione di aggregazione APPROX_COUNT_DISTINCT restituisce il numero approssimativo di valori univoci non Null in un gruppo.

Questa funzionalità è disponibile a partire da SQL Server 2019 (15.x), indipendentemente dal livello di compatibilità.

Per altre informazioni, vedere APPROX_COUNT_DISTINCT.

Percentile approssimativo

Si applica a: SQL Server, a partire da SQL Server 2022 (16.x) e al database SQL di Azure

Queste funzioni di aggregazione calcolano i percentili per un set di dati di grandi dimensioni con limiti di errore basati sulla classificazione accettabili per prendere decisioni rapide usando funzioni di aggregazione percentile approssimative.

Per altre informazioni, vedere APPROX_PERCENTILE_DISC e APPROX_PERCENTILE_CONT

Modalità batch su rowstore

Si applica a: SQL Server, a partire da SQL Server 2019 (15.x) e database SQL di Azure

La modalità batch per rowstore abilita l'esecuzione in modalità batch per i carichi di lavoro analitici senza richiedere indici columnstore. Questa funzionalità supporta l'esecuzione in modalità batch e i filtri bitmap per gli heap su disco e gli indici con albero B. La modalità batch per rowstore abilita il supporto per tutti gli operatori esistenti abilitati alla modalità batch.

Le query esistenti che possono trarre vantaggio dalla modalità batch nel rowstore includono:

• Hash join tra tabelle rowstore di grandi dimensioni
• Query con GROUP BY su molti valori distinti
• Funzioni di aggregazione come SUM, COUNTMIN, , MAX,AVG
• Query di funzione Window con OVER, PARTITION BYe ORDER BY, incluse le funzioni ROW_NUMBER di aggregazione e RANK

Per altre informazioni sulle prestazioni delle funzioni finestra, vedere Considerazioni sulle prestazioni nel riferimento alla OVER clausola.

Panoramica dell’esecuzione in modalità batch

SQL Server 2012 (11.x) ha introdotto una nuova funzionalità per accelerare i carichi di lavoro analitici: gli indici columnstore. In ogni versione successiva di SQL Server sono stati estesi i casi d'uso e migliorate le prestazioni degli indici columnstore. La creazione di indici columnstore nelle tabelle può migliorare le prestazioni per i carichi di lavoro analitici. Esistono tuttavia due set di tecnologie correlate ma distinte:

• Con gli indici columnstore, le query analitiche accedono solo ai dati nelle colonne necessarie. La compressione di pagina nel formato columnstore è anche più efficace rispetto alla compressione di pagina negli indici rowstore tradizionali.
• Con l'elaborazione in modalità batch, gli operatori di query elaborano i dati in modo più efficiente, Operano su un insieme di righe anziché su una singola riga alla volta. All'elaborazione in modalità batch sono associati molti altri miglioramenti per la scalabilità. Per altre informazioni sulla modalità batch, vedere Modalità di esecuzione.

I due set di funzionalità interagiscono per migliorare input/output (I/O) e uso della CPU:

• Usando gli indici columnstore, una quantità maggiore di dati può essere contenuta in memoria. Questo riduce il carico di lavoro di I/O.
• L'elaborazione in modalità batch usa in modo più efficiente la CPU.

Le due tecnologie sfruttano i vantaggi reciproci laddove possibile. Ad esempio, le aggregazioni in modalità batch possono essere valutate come parte di un'analisi dell'indice columnstore. Anche i dati columnstore compressi tramite la codifica run-length vengono elaborati in modo molto più efficiente nelle operazioni di join e aggregazione in modalità batch.

È tuttavia importante comprendere che le due funzionalità sono indipendenti:

• È possibile ottenere piani in modalità riga che utilizzano indici columnstore.
• È possibile ottenere piani in modalità batch che usano solo indici rowstore.

Usando le due funzionalità insieme, si ottengono in genere i risultati migliori. Prima di SQL Server 2019 (15.x), SQL Server Query Optimizer ha considerato l'elaborazione in modalità batch solo per le query che coinvolgono almeno una tabella con un indice columnstore.

Gli indici columnstore potrebbero non essere appropriati per alcune applicazioni. Un'applicazione potrebbe usare altre funzionalità non supportate con gli indici columnstore. Ad esempio, le modifiche sul posto non sono compatibili con la compressione columnstore. Quindi, i trigger non sono supportati sulle tabelle con indici columnstore clusterizzati. Ancora più importante, gli indici columnstore comportano un sovraccarico per le istruzioni DELETE e UPDATE.

Per alcuni carichi di lavoro ibridi analitico-transazionali l'overhead di un carico di lavoro transazionale è maggiore dei vantaggi offerti dagli indici columnstore. Questi scenari possono trarre vantaggio dall'uso ottimale della CPU tramite l'elaborazione solo in modalità batch. Questo è il motivo per cui la modalità batch per rowstore considera la modalità batch per tutte le query, indipendentemente dal tipo di indici interessati.

Carichi di lavoro che possono trarre vantaggio dalla modalità batch per rowstore

I carichi di lavoro seguenti possono trarre vantaggio dalla modalità batch per rowstore:

• Una parte significativa del carico di lavoro è costituita da query analitiche. In genere queste query usano operatori come join o aggregazioni che elaborano centinaia di migliaia di righe o più.
• Il carico di lavoro è basato sulla CPU. Se il collo di bottiglia è di I/O, è comunque consigliabile prendere in considerazione un indice columnstore, se possibile.
• La creazione di un indice columnstore comporta un sovraccarico eccessivo per la parte transazionale del carico di lavoro. In alternativa, la creazione di un indice columnstore non è fattibile perché l'applicazione dipende da una funzionalità non ancora supportata con gli indici columnstore.

Che cosa cambia con la modalità batch per rowstore

La modalità batch in rowstore richiede che il database sia di livello di compatibilità 150.

Anche se una query non accede ad alcuna tabella con indici columnstore, il processore di query utilizza euristiche per decidere se considerare la modalità batch. L'euristica è costituita da questi controlli:

1. Un controllo iniziale delle dimensioni delle tabelle, degli operatori usati e delle cardinalità stimate nella query di input.
2. Checkpoint aggiuntivi, man mano che Query Optimizer individua piani nuovi e più economici per la query. Se questi piani alternativi non usano in modo significativo la modalità batch, Query Optimizer smette di esplorare le alternative in modalità batch.

Se la modalità batch per rowstore viene usata, la modalità di esecuzione effettiva visualizzata nel piano di query è la modalità batch. L'operatore di scansione usa la modalità batch per gli heap su disco e gli indici B-tree. Questa analisi in modalità batch può valutare i filtri bitmap in modalità batch. Nel piano è possibile vedere anche altri operatori della modalità batch. Alcuni esempi sono gli hash join, le aggregazioni basate su hash, gli ordinamenti, le aggregazioni finestra, i filtri, la concatenazione e gli operatori scalari di calcolo.

Remarks

I piani di esecuzione delle query non usano sempre la modalità batch. Query Optimizer potrebbe decidere che la modalità batch non è utile per la query.

Lo spazio di ricerca di Query Optimizer cambia. Il piano in modalità riga eventualmente ottenuto potrebbe quindi non essere uguale a quello ottenuto a un livello di compatibilità inferiore e il piano in modalità batch eventualmente ottenuto potrebbe non essere uguale a quello ottenuto con un indice columnstore.

I piani potrebbero anche cambiare per le query che combinano gli indici columnstore e rowstore a causa della nuova scansione rowstore in modalità batch.

Esistono attualmente alcune limitazioni per la nuova modalità batch per analisi di rowstore:

• Non si applica alle tabelle OLTP ottimizzate per la memoria né agli indici diversi da heap su disco e B-tree.
• Non verrà neanche attivata in caso di recupero o filtro di una colonna LOB (Large Object). Questa limitazione comprende i set di colonne sparse e le colonne XML.

Esistono query per cui la modalità batch non viene utilizzata nemmeno con gli indici columnstore. Un esempio sono le query che richiedono cursori. Queste stesse esclusioni vengono estese anche alla modalità batch per rowstore.

Configurare la modalità batch per rowstore

La BATCH_MODE_ON_ROWSTOREconfigurazione con ambito database è attivata per impostazione predefinita.

È possibile disabilitare la modalità batch per rowstore senza cambiare il livello di compatibilità del database:

-- 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;

È possibile disabilitare la modalità batch per rowstore tramite configurazione con ambito database. È tuttavia possibile eseguire l'override dell'impostazione a livello di query usando l'hint per la query ALLOW_BATCH_MODE. L'esempio seguente abilita la modalità batch per rowstore anche con la funzionalità disabilitata tramite la configurazione con ambito database:

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'));

È anche possibile disabilitare la modalità batch per rowstore per una query specifica usando l'hint per la query DISALLOW_BATCH_MODE. Vedere l'esempio seguente:

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'));

Funzionalità di feedback per l'elaborazione delle query

Le funzionalità di feedback per l'elaborazione delle query fanno parte della famiglia di funzionalità di elaborazione intelligente delle query.

Il feedback sull'elaborazione delle query è un processo in base al quale Query Processor in SQL Server, database SQL di Azure e Istanza gestita di SQL di Azure usa dati storici sull'esecuzione di una query per decidere se la query potrebbe ricevere assistenza da una o più modifiche alla modalità di compilazione ed esecuzione. I dati sulle prestazioni vengono raccolti in Query Store, con vari suggerimenti per migliorare l'esecuzione delle query. In caso di esito positivo, le modifiche apportate al disco vengono mantenute in memoria e/o in Query Store per un uso futuro. Se i suggerimenti non producono miglioramenti sufficienti, vengono eliminati e la query continua a essere eseguita senza tale feedback.

Per informazioni sulle funzionalità di feedback per l'elaborazione delle query disponibili in versioni diverse di SQL Server o in database SQL di Azure o Istanza gestita di SQL di Azure, vedere Elaborazione intelligente delle query nei database SQL o negli articoli seguenti per ogni funzionalità di feedback.

Feedback della concessione di memoria

La funzionalità di feedback per l'allocazione della memoria è stata introdotta progressivamente nel corso delle ultime versioni principali di SQL Server.

Feedback delle concessioni di memoria in modalità batch

Per informazioni sul feedback delle concessioni di memoria in modalità batch, vedere Feedback sulle concessioni di memoria in modalità batch.

Feedback delle concessioni di memoria in modalità riga

Per informazioni sul feedback delle concessioni di memoria in modalità riga, vedere Feedback sulle concessioni di memoria in modalità riga.

Feedback delle concessioni di memoria in modalità percentile e persistenza

Per informazioni sul feedback sull'assegnazione della memoria in percentile e in modalità di persistenza, vedere Feedback sull'assegnazione della memoria in percentile e in modalità di persistenza.

Feedback sul grado di parallelismo (DOP)

Per informazioni sui feedback DOP, vedere Feedback sul grado di parallelismo (DOP).

Feedback sulla stima della cardinalità (CE)

Per informazioni sul feedback della stima di cardinalità, vedere Feedback sulla stima di cardinalità (CE).

Forzatura ottimizzata del piano con Query Store

Per informazioni sulla forzatura del piano ottimizzato con Query Store, vedere Forzatura del piano ottimizzato con Query Store.

Contenuti correlati

• Join (SQL Server)
• Modalità di esecuzione
• Guida sull'architettura di elaborazione delle query
• Riferimento dell'operatore per piani di esecuzione logici e fisici
• ALTER DATABASE SCOPED CONFIGURATION (Transact-SQL)
• Novità di SQL Server 2017
• Novità di SQL Server 2019
• Novità di SQL Server 2022
• Dimostrazione dell'elaborazione di query intelligenti
• Valutazione delle espressioni ed elaborazione delle costanti
• Demo di elaborazione di query intelligenti in GitHub
• Centro prestazioni per il motore di database di SQL Server e il database SQL di Azure
• Monitorare le prestazioni tramite Query Store
• Procedure consigliate per monitorare i carichi di lavoro con Query Store