Perché "Seleziona * in targeting da sourcetable" è più veloce di "Inserisci in targeting select * da sourcetable

Questo titolo è la domanda. Sono curioso di sapere la risposta. Qualcuno ha detto

seleziona in è minimamente registrato nel database del modello di recupero semplice ... Non ci sono entrato affatto.

Estratto da Microsoft:

La quantità di registrazione per SELECT ... INTO dipende dal modello di recupero in vigore per il database. In base al modello di recupero semplice o al modello di recupero registrato in blocco, le operazioni in blocco vengono registrate in modo minimale. Con una registrazione minima, l'utilizzo dell'istruzione SELECT ... INTO può essere più efficiente della creazione di una tabella e quindi del popolamento della tabella con un'istruzione INSERT

In cerca di aiuto

Grazie

sql-server

che database stai usando? Quali strutture sono le tabelle? Come hai misurato che uno è più veloce dell'altro?

Sarei sorpreso se ci fosse qualche differenza su un DBMS ben scritto.

Database: SQL Server 20005 ... e ho sentito questo .. anche se non sono sicuro al 100% ... Sto cercando ciò che dicono gli altri popoli .. Come ho detto che qualcuno mi ha detto questo ...

Trovato un collegamento che conferma che SELECT INTOpuò essere minimamente registrato quando non si utilizza il recupero completo.

— Damien_The_Unbeliever l'

Un paio di idee / teorie:

SELECT INTO ... consente all'RDBMS di determinare l'ordinamento in base all'ordine della tabella originale. Se si inserisce in una tabella esistente, potrebbe essere necessario un ordinamento per abbinare uno o più indici cluster.

NessunSELECT INTO... indice : quando RDBMS lo sa per certo, non ci sono indici preesistenti da aggiornare.

Nessuna contesa : poiché la tabella in cui si sta inserendo non esiste, SQL Server non deve preoccuparsi del blocco a livello di riga o della gestione delle contese. Nient'altro può fare riferimento alla tabella che crei poiché non esiste.

Detto questo, ci sono altri modi per inserirli in una tabella molto rapidamente.

Assicurati che le chiavi di indice del cluster corrispondano quando possibile. Ciò significa che non esiste un ordinamento al volo
Disabilita tutti gli indici non cluster. Spiega da sé.
Impostare la modalità di ripristino su semplice e tracciare il flag 610 su ON. Utilizzare il TABLOCKsuggerimento sulla tabella di destinazione e il NOLOCKsuggerimento sulla tabella di origine.

Ad esempio, supponiamo che tablea e tableb abbiano lo stesso indice cluster:

INSERT INTO TableB WITH (TABLOCK)
SELECT <Columns>
FROM TableA WITH (NOLOCK)

Nella mia esperienza, ciò è più veloce rispetto all'utilizzo SELECT INTO...e alla creazione successiva dell'indice cluster. Si noti che questo può funzionare anche su una tabella che contiene già dei dati che rappresentano uno scenario molto più utile.

MODIFICARE:

Ecco un white paper straordinariamente dettagliato di MS per le prestazioni di caricamento dei dati in SQL Server 2008.

— JNK
fonte

Risposta molto approfondita JNK. Inoltre, se implementato correttamente e il modello di recupero non è completo, una semplice attività del flusso di dati SSIS può essere più veloce di una di queste. Perché? Entrambi i precedenti emettono un blocco esclusivo (Read è multi-thread ma write è single thread). Finché viene utilizzato un blocco tabella con l'adattatore di destinazione, SSIS utilizzerà un blocco di aggiornamento in blocco (sia in lettura che in scrittura sono multi-thread).

— Brian