Ci sono vantaggi nell'utilizzo di tabelle temporanee su tabelle derivate in SQL Server?


8

Ho letto che le tabelle derivate hanno prestazioni migliori rispetto alle tabelle temporanee, ma comunque molti sviluppatori di SQL Server preferiscono le seconde. Perché? Devo fare query con dati di grandi dimensioni (milioni di record) e voglio essere sicuro di utilizzare la scelta migliore.

CREATE TABLE A(
    id BIGINT IDENTITY(1,1) NOT NULL,
    field1 INT NOT NULL,
    field2 VARCHAR(50) NULL,
);

CREATE TABLE B(
    id INT IDENTITY(1,1) NOT NULL,
    field1 VARCHAR(10) NULL,
    field2 INT NULL
);

INSERT INTO A 
    (field1,field2)
VALUES 
    (1,'a'),(2,'b'),(3,'c'),(2,'d'),(5,'e'),
    (6,'f'),(7,'g'),(8,'h'),(9,'i'),(2,'j');

INSERT INTO B 
    (field1,field2)
VALUES 
    ('a',1),('b',2),('c',3),('d',4),('e',5),
    ('f',6),('g',7),('h',8),('i',9),('j',2),('k',3);

DECLARE @begin INT=0,@end INT=200;

Tabelle derivate

/*derived tables*/
SELECT 
    C.id,C.field1,C.field2,C.field3 
FROM
(
    SELECT
        A.id,A.field1,A.field2,B.field2 AS field3, 
        ROW_NUMBER() OVER (ORDER BY A.id) AS iRow
    FROM 
        A INNER JOIN B ON A.field1=B.id
) C
WHERE iRow BETWEEN @begin AND @end;

Tabelle temporanee

/*temporary tables*/
CREATE TABLE #C (
    iRow INT IDENTITY(1,1),
    id bigint,
    field1 INT,
    field2 VARCHAR(50),
    field3 INT );

INSERT INTO #C 
    (id,field1,field2,field3)
SELECT TOP 1000 
    A.id,A.field1,A.field2,B.field2 
FROM  
    A INNER JOIN B ON A.field1=B.id
ORDER BY 
    A.id;

SELECT id,field1,field2,field3 
FROM #C 
WHERE iRow BETWEEN @begin AND @end;

DROP TABLE #C;

1
Hai un SELECT TOP 1000senza nessuno ORDER BY, non va bene. Penso che sia necessario aggiungere ORDER BY A.id;i due modi per essere equivalenti.
ypercubeᵀᴹ

È solo un esempio. L'obiettivo è mostrare l'argomento principale della mia domanda.
norgematos,

Risposte:


6

@ user16484 ti ha già indirizzato a Quale ha prestazioni migliori: tabelle derivate o tabelle temporanee nel commento.

Vedi anche Tabella Temp 'vs' Variabile tabella 'vs' CTE. che copre anche le tabelle derivate.

Un breve riepilogo: le tabelle #temp possono essere indicizzate, possono avere indici / vincoli UNICI, possono essere riferimenti più di una volta nella stessa query, possono essere referenziati (FROM o JOIN) da più di una query. È possibile fare riferimento alle tabelle derivate (FROM o JOIN) una volta in una query.

Dal punto di vista delle prestazioni, estrarre Profiler per SQL: BatchCompleted e RPC: Completato, osservare le colonne Lettura, Scrittura, CPU e Durata e vedere cosa fanno alcune esecuzioni di tabelle derivate rispetto alle tabelle #temp rispetto alle tabelle #temp indicizzate ogni query particolare.

In generale, se lo utilizzerai più di una volta, la tabella #temp vince. Se stai unendo molti tavoli, la tabella #temp probabilmente vince. Se ti unisci solo a pochi tavoli, la tabella derivata ha una ragionevole possibilità di vincere. Benchmark it!


6

In generale, dipende dalle tue query particolari e dalla dimensione dei risultati temporanei.

Per lo scenario specifico indicato, che è il paging, le tabelle temporanee sono totalmente inutili. Perché dovresti voler salvare 1000 righe in una tabella temporanea solo per restituire il 1 ° 200? L'utilizzo di una tabella "derivata" o di un CTE in questo scenario è molto più efficiente, poiché l'intero set di risultati non deve essere archiviato da nessuna parte, o nella maggior parte dei casi nemmeno prodotto. Ad esempio, quando si richiede la prima pagina di 200 righe, solo le prime 200 righe dovranno essere recuperate dalle tabelle di base (supponendo che gli indici esistenti possano supportare l'ordinamento richiesto nella query).


1
+1, anche se aggiungerei che l'utilizzo di tabelle derivate consente allo Strumento per ottimizzare le query di gestire entrambe le query contemporaneamente. Questo può essere buono o talvolta negativo, di nuovo "a seconda della query specifica". Ecco perché è sempre bene testare entrambi (su dati reali, non su dati di esempio) piuttosto che indovinare :-).
Solomon Rutzky,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.