Funzionalità di elaborazione di query intelligenti in dettaglio.

  • Articolo

Si applica a: SQL Server Database SQL di Azure Istanza gestita di SQL di Azure

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:

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 Join adattivo definisce una soglia che viene usata per stabilire quando passare a un piano Cicli annidati. 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 interleaved per funzioni con valori di tabella con più istruzioni

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 interleaved riduce i problemi di prestazioni del carico di lavoro dovute alle stime della cardinalità fisse associate alle funzioni con valori di tabella con istruzioni multiple (MSTVF). Con l'esecuzione interleaved, il conteggio effettivo delle righe viene usato per adottare decisioni più mirate relativamente a un piano di query downstream.

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

L'esecuzione interleaved cambia il limite unidirezionale tra le fasi di ottimizzazione ed esecuzione nel caso di un'esecuzione a query singola e consente l'adattamento dei piani in base alle stime di cardinalità aggiornate. Se durante l'ottimizzazione il motore di database rileva un candidato per l'esecuzione interleaved che usa funzioni con valori di tabella con istruzioni multiple (MSTVFs) si sospende l'ottimizzazione, si esegue il sottoalbero appropriato, si acquisiscono stime di cardinalità accurate e quindi si riprende l'ottimizzazione per le operazioni downstream.

L'immagine seguente rappresenta un output di Statistiche query dinamiche, un subset di un piano di esecuzione complessivo che mostra l'impatto delle stime della cardinalità fisse da funzioni con valori di tabella con istruzioni multiple (MSTVFs).

È 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 il flusso della scansione di tabella MSTVF registra 527.597 righe, come visualizzato in Statistiche query dinamiche nel confronto 527597 di 100 tra valore effettivo e valore stimato. Si tratta di una deviazione notevole rispetto alla stima fissa.
  • Per l'operazione di join a cicli annidati è previsto che il lato esterno del join restituisca solo 100 righe. Dato l'elevato numero di righe di fatto restituite dalla funzione MSTVF, in questo caso può risultare utile la scelta di un altro algoritmo di join.
  • Per l'operazione Hash Match osservare il piccolo simbolo di avviso, che in questo caso indica un evento di distribuzione su disco.

Immagine di un flusso di riga del piano di esecuzione rispetto alle righe stimate.

Confrontare il piano precedente al piano reale generato con l'esecuzione interleaved attivata:

Immagine del piano di esecuzione interfogliato.

  • Si noti che la scansione di tabella MSTVF ora presenta una stima di cardinalità accurata. Si noti anche il riordino della scansione di tabella e delle altre operazioni.
  • Quanto agli algoritmi di join l'operazione di join a cicli annidati è stata sostituita da un'operazione Hash Match, più indicata con un numero di righe molto elevato.
  • Si noti anche che gli avvisi di distribuzione su disco non sono più presenti, in quanto viene allocata una maggior quantità di memoria sulla base del conteggio reale delle righe del flusso della scansione di tabella MSTVF.

Istruzioni idonee per l'esecuzione interleaved

Attualmente le funzioni MSTVF che fanno riferimento a istruzioni nell'esecuzione interleaved devono essere di sola lettura e non far parte di un'operazione di modifica dei dati. Le funzioni MSTV, poi, sono idonee per l'esecuzione interleaved solo se non usano costanti di runtime.

Vantaggi dell'esecuzione interleaved

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.

L'esecuzione interleaved può risultare vantaggiosa nelle query in cui:

  • Si registra uno scarto notevole tra il numero di righe stimato e il numero reale nel set di risultati intermedio (in questo caso la funzione MSTVF).
  • La query nel suo complesso è sensibile alla variazione delle dimensioni del risultato intermedio. Ciò accade di solito quando nel piano della query è presente un albero complesso sopra il sottoalbero. Una semplice istruzione SELECT * di una funzione MSTVF non trae vantaggio dall'esecuzione interleaved.

Sovraccarichi dell'esecuzione interleaved

Il sovraccarico previsto è minimo o nullo. Le funzioni con valori di tabella con istruzioni multiple (MSTVFs) venivano già materializzate prima dell'introduzione dell'esecuzione interleaved, ma ora grazie all'abilitazione dell'ottimizzazione differita tali funzioni usano la stima della cardinalità del set di righe materializzate. È possibile che in seguito alle modifiche alcuni piani registrino un miglioramento della cardinalità per il sottoalbero ma una riduzione dell'efficienza per la query nel suo complesso. La prevenzione può includere il ripristino del livello di compatibilità o l'uso di Query Store per imporre la versione non regredita del piano.

Esecuzione interleaved ed esecuzioni consecutive

Dopo che un piano di esecuzione interleaved viene memorizzato nella cache, il piano con le stime aggiornate alla prima esecuzione viene usato per le esecuzioni consecutive e non viene creata di nuovo l'istanza di esecuzione interleaved.

Rilevare le attività di esecuzione interleaved

È possibile visualizzare gli attributi d'uso nel piano di esecuzione query:

Attributo del piano di esecuzione Descrizione
ContainsInterleavedExecutionCandidates Si applica al nodo QueryPlan. Quando è true, il piano contiene candidati per l'esecuzione interleaved.
IsInterleavedExecuted Attributo dell'elemento RuntimeInformation in RelOp per il nodo TVF. Quando è true, l'operazione è stata materializzata come parte di un'operazione di esecuzione interleaved.

È anche possibile rilevare le occorrenze di esecuzione interleaved con i seguenti eventi estesi:

XEvent Descrizione
interleaved_exec_status Questo evento viene generato quando si verifica l'esecuzione interleaved.
interleaved_exec_stats_update Questo evento descrive le stime della cardinalità aggiornate dall'esecuzione interleaved.
Interleaved_exec_disabled_reason Questo evento viene generato quando in una query con un possibile candidato per l'esecuzione interleaved non viene applicata tale modalità di esecuzione.

Per consentire all'esecuzione interleaved di rivedere le stime della cardinalità MSTVF è necessario eseguire la 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 interleaved

Se un piano è viene cancellato o espulso dalla cache, durante l'esecuzione della query l'esecuzione interleave viene usata da una nuova compilazione. Un'istruzione che usa OPTION (RECOMPILE) crea un nuovo piano usando l'esecuzione interleaved e non lo memorizza nella cache.

Esecuzione interleaved e interoperabilità di Query Store

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

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

È possibile disabilitare l'esecuzione interleaved nell'ambito del database o dell'istruzione mantenendo comunque la compatibilità sul livello 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 definendo DISABLE_INTERLEAVED_EXECUTION_TVF come hint per la query USE HINT. Ad esempio:

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

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

Inlining di funzioni definite dall'utente scalari

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

L'inlining di funzioni definite dall'utente scalari trasforma automaticamente le funzioni definite dall'utente scalari in espressioni relazionali e le incorpora nella query SQL chiamante. Questa trasformazione migliora le prestazioni dei carichi di lavoro che sfruttano le funzioni definite dall'utente scalari. L'inlining di funzioni definite dall'utente scalari facilita l'ottimizzazione basata sui costi delle operazioni all'interno delle funzioni definite dall'utente. 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 nel livello di compatibilità del database 150.

Per altre informazioni, vedere Inlining di funzioni definite dall'utente scalari.

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 sui conteggi delle righe verranno quindi usate per ottimizzare le operazioni del piano a valle.

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 riusato da query consecutive, fino a quando non viene rimosso o ricompilato.

Il conteggio delle righe delle variabili di tabella usato per la compilazione del piano iniziale rappresenta un valore tipico e potrebbe essere diverso da un'ipotesi di conteggio di righe fisso. Se è diverso, è un vantaggio per le operazioni a valle. 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. Ad 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 sensibile ai parametri

Si applica a: SQL Server 2022 (16.x) Database Azure SQL Istanza gestita di SQL di Azure

L'ottimizzazione del piano sensibile ai parametri (PSP) fa parte della famiglia di funzionalità di elaborazione di query intelligenti. 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.

Elaborazione delle query approssimativa

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.

Count Distinct approssimato

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 (Transact-SQL).

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 (Transact-SQL) e APPROX_PERCENTILE_CONT (Transact-SQL)

Modalità batch per 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.

Nota

Nella documentazione viene usato in modo generico il termine albero B in riferimento agli indici. Negli indici rowstore, il motore di database implementa un albero B+. Ciò non si applica a indici columnstore o a indici in tabelle ottimizzate per la memoria. Per altre informazioni, vedere Architettura e guida per la progettazione degli indici SQL Server e Azure SQL.

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, perché agiscono su un batch di righe invece che su una riga per 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 indice columnstore, viene salvata in memoria una quantità maggiore di dati. 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 con la codifica RLE vengono elaborati in modo molto più efficiente con i join e le aggregazioni in modalità batch.

È tuttavia importante tenere presente che le due funzionalità sono indipendenti:

  • È possibile ottenere piani in modalità riga che usano 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. Le modifiche sul posto, ad esempio, non sono compatibili con la compressione columnstore, quindi i trigger non sono supportati nelle tabelle con indici columnstore in cluster, ma soprattutto gli indici columnstore aggiungono un overhead 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 sono le operazioni di I/O, è comunque consigliabile prendere in considerazione un indice columnstore, se possibile.
  • La creazione di un indice columnstore aggiunge un overhead eccessivo alla parte transazionale del carico di lavoro oppure la creazione di un indice columnstore non è implementabile perché l'applicazione dipende da una funzionalità non ancora supportata con gli indici columnstore.

Nota

La modalità batch per rowstore consente solo di ridurre l'utilizzo della CPU. Se il collo di bottiglia è associato alle operazioni di I/O e i dati non sono già memorizzati nella cache (cache "a freddo"), la modalità batch per rowstore non ridurrà il tempo trascorso per le query. Analogamente, se la memoria del computer non è sufficiente per memorizzare nella cache tutti i dati, un miglioramento delle prestazioni è improbabile.

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 a nessuna tabella con indici columnstore, Query Processor usa l'euristica per decidere se prendere in considerazione 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 analisi usa la modalità batch per gli heap su disco e gli indici albero B. 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.

Osservazioni:

I piani di 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 analisi rowstore in modalità batch.

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

  • Non verrà applicata per le tabelle OLTP in memoria o per qualsiasi indice diverso da heap su disco e alberi B.
  • Non verrà neanche attivata in caso di recupero o filtro di una colonna LOB (Large Object). Questa limitazione include set di colonne di tipo sparse e colonne XML.

Esistono query per le quali la modalità batch non viene usata neppure 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 configurazione con ambito database BATCH_MODE_ON_ROWSTORE è per impostazione predefinita su ON.

È 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

Il feedback sulle concessioni di memoria è stato introdotto in parti rispetto alle principali versioni precedenti 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 sulle concessioni di memoria percentile e in modalità persistenza, vedere Feedback sulle concessioni di memoria in modalità percentile e persistenza.

Feedback sul grado di parallelismo (DOP)

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

Feedback stima di cardinalità (CE)

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

Uso forzato del piano ottimizzato con Query Store

Per informazioni sull'uso forzato del piano ottimizzato con Query Store, vedere Utilizzo forzato del piano ottimizzato con Query Store.

Contenuto correlato