Esiste una differenza di prestazioni tra CTE, sottoquery, tabella temporanea o variabile tabella?

In questa eccellente domanda SO , sono state discusse le differenze tra CTEe sub-queries.

Vorrei chiedere specificamente:

In quale circostanza ciascuna delle seguenti è più efficiente / più veloce?

• CTE
• Sotto-Query
• Tabella temporanea
• Variabile di tabella

Tradizionalmente, ho usato molte cose temp tablesin fase di sviluppo stored procedures, in quanto sembrano più leggibili di molte query secondarie intrecciate.

Non-recursive CTEs incapsulano molto bene insiemi di dati e sono molto leggibili, ma ci sono circostanze specifiche in cui si può dire che funzioneranno sempre meglio? o si tratta di dover sempre giocherellare con le diverse opzioni per trovare la soluzione più efficiente?

MODIFICARE

Recentemente mi è stato detto che in termini di efficienza, le tabelle temporanee sono una buona prima scelta in quanto hanno un istogramma associato, cioè le statistiche.

SQL è un linguaggio dichiarativo, non un linguaggio procedurale. Cioè, si costruisce un'istruzione SQL per descrivere i risultati desiderati. Non stai dicendo al motore SQL come fare il lavoro.

Come regola generale, è una buona idea lasciare che il motore SQL e l'ottimizzatore SQL trovino il miglior piano di query. Ci sono molti anni di lavoro personale che vanno allo sviluppo di un motore SQL, quindi lascia che gli ingegneri facciano ciò che sanno fare.

Naturalmente, ci sono situazioni in cui il piano di query non è ottimale. Quindi si desidera utilizzare i suggerimenti per le query, ristrutturare la query, aggiornare le statistiche, utilizzare tabelle temporanee, aggiungere indici e così via per ottenere prestazioni migliori.

Per quanto riguarda la tua domanda. Le prestazioni di CTE e sottoquery dovrebbero, in teoria, essere le stesse poiché entrambe forniscono le stesse informazioni a Query Optimizer. Una differenza è che un CTE usato più di una volta potrebbe essere facilmente identificato e calcolato una volta. I risultati potrebbero quindi essere memorizzati e letti più volte. Sfortunatamente, SQL Server non sembra trarre vantaggio da questo metodo di ottimizzazione di base (è possibile chiamare questa eliminazione di subquery comune).

Le tabelle temporanee sono una questione diversa, perché stai fornendo ulteriori indicazioni su come eseguire la query. Una delle principali differenze è che l'ottimizzatore può utilizzare le statistiche della tabella temporanea per stabilire il suo piano di query. Ciò può comportare miglioramenti delle prestazioni. Inoltre, se si dispone di un CTE (sottoquery) complicato che viene utilizzato più di una volta, la sua memorizzazione in una tabella temporanea spesso migliorerà le prestazioni. La query viene eseguita una sola volta.

La risposta alla tua domanda è che devi giocare per ottenere le prestazioni che ti aspetti, in particolare per query complesse che vengono eseguite su base regolare. In un mondo ideale, Query Optimizer trova il percorso di esecuzione perfetto. Anche se spesso accade, potresti essere in grado di trovare un modo per ottenere prestazioni migliori.

Non c'è una regola. Trovo i CTE più leggibili e li uso a meno che non presentino qualche problema di prestazioni, nel qual caso indago il problema reale piuttosto che indovinare che il CTE è il problema e provo a riscriverlo usando un approccio diverso. Di solito c'è un problema in più rispetto al modo in cui ho scelto di dichiarare dichiaratamente le mie intenzioni con la query.

Ci sono certamente casi in cui è possibile svelare CTE o rimuovere sottoquery e sostituirle con una tabella #temp e ridurre la durata. Ciò può essere dovuto a varie cose, come le statistiche obsolete, l'incapacità di ottenere statistiche accurate (ad esempio, unirsi a una funzione con valori di tabella), il parallelismo o persino l'incapacità di generare un piano ottimale a causa della complessità della query ( nel qual caso la sua rottura può dare all'ottimizzatore una possibilità di combattimento). Ma ci sono anche casi in cui l'I / O coinvolto nella creazione di una tabella #temp può superare gli altri aspetti delle prestazioni che possono rendere una particolare forma del piano usando un CTE meno attraente.

Onestamente, ci sono troppe variabili per fornire una risposta "corretta" alla tua domanda. Non esiste un modo prevedibile per sapere quando una query può dare un suggerimento a favore di un approccio o di un altro: basta sapere che, in teoria, la stessa semantica per un CTE o una singola sottoquery dovrebbe eseguire esattamente lo stesso. Penso che la tua domanda sarebbe più preziosa se presenti alcuni casi in cui ciò non è vero: è possibile che tu abbia scoperto una limitazione nell'ottimizzatore (o ne abbia scoperto uno noto) o che le tue query non siano semanticamente equivalenti o quello contiene un elemento che ostacola l'ottimizzazione.

Quindi suggerirei di scrivere la query in un modo che ti sembra più naturale e deviare solo quando scopri un reale problema di prestazioni dell'ottimizzatore. Personalmente li classifico CTE, quindi subquery, con la tabella #temp come ultima risorsa.

#temp è materalizzato e CTE no.

CTE è solo una sintassi, quindi in teoria è solo una sottoquery. Viene eseguito. #temp è materializzato. Quindi un CTE costoso in un join eseguito più volte potrebbe essere migliore in un #temp. D'altra parte, se si tratta di una valutazione semplice che non viene eseguita, ma alcune volte, non vale il sovraccarico di #temp.

Ci sono alcune persone su SO che non amano la variabile table ma mi piacciono poiché sono materializzate e più veloci da creare rispetto a #temp. Ci sono momenti in cui Query Optimizer funziona meglio con un #temp rispetto a una variabile di tabella.

La possibilità di creare un PK su una variabile #temp o table fornisce all'ottimizzatore di query più informazioni di un CTE (poiché non è possibile dichiarare un PK su un CTE).

Solo 2 cose che penso rendono SEMPRE preferibile usare una tabella # Temp piuttosto che un CTE sono:

1. Non è possibile inserire una chiave primaria in un CTE, pertanto i dati a cui accede il CTE dovranno attraversare ciascuno degli indici nelle tabelle del CTE anziché accedere al PK o all'indice nella tabella temporanea.

2. Poiché non è possibile aggiungere vincoli, indici e chiavi primarie a un CTE, sono più inclini a bug che si insinuano e dati errati.

-domani ieri

Ecco un esempio in cui i vincoli #table possono prevenire dati errati che non è il caso di CTE

DECLARE @BadData TABLE ( 
                       ThisID int
                     , ThatID int );
INSERT INTO @BadData
       ( ThisID
       , ThatID
       ) 
VALUES
       ( 1, 1 ),
       ( 1, 2 ),
       ( 2, 2 ),
       ( 1, 1 );

IF OBJECT_ID('tempdb..#This') IS NOT NULL
    DROP TABLE #This;
CREATE TABLE #This ( 
             ThisID int NOT NULL
           , ThatID int NOT NULL
                        UNIQUE(ThisID, ThatID) );
INSERT INTO #This
SELECT * FROM @BadData;
WITH This_CTE
     AS (SELECT *
           FROM @BadData)
     SELECT *
       FROM This_CTE;