UPDATE rispetto alle prestazioni INSERTO

Question

Sono corretto supporre che una query UPDATE richieda più risorse di una query INSERT?

Grazie,

Answer 1

io non sono un guru del database ma qui i miei due centesimi:

Personalmente non credo che avete molto da fare in questo senso, anche se INSERT sarebbe più veloce (tutti a essere provato), puoi convertire un aggiornamento in un inserto ?! francamente non penso che tu possa farlo tutte le volte.

durante un INSERIMENTO, in genere non è necessario utilizzare DOVE per identificare quale riga aggiornare ma, a seconda degli indici su tale tabella, l'operazione può comportare dei costi.

durante un aggiornamento se non si modifica alcuna colonna inclusa in alcun indice si potrebbe avere un'esecuzione rapida, se la clausola where è semplice e abbastanza veloce.

niente è scritto su pietre e davvero immagino che dipenda dall'intera configurazione del database, indici e così via.

comunque, abbiamo trovato questo come riferimento:

Top 84 MySQL Performance Tips

Answer 2

Dipende. Un semplice UPDATE che utilizza una chiave primaria nella clausola WHERE e aggiorna solo un singolo campo non indicizzato sarebbe probabilmente meno costoso di un INSERT nella stessa tabella. Ma anche questo dipende dal motore di database coinvolto. Un UPDATE che implicava la modifica di molti campi indicizzati, tuttavia, potrebbe essere più costoso di INSERT su quella tabella poiché sarebbero necessarie ulteriori modifiche alla chiave dell'indice. Un UPDATE con una clausola WHERE mal costruita che richiedeva una scansione di tabelle di milioni di record sarebbe sicuramente più costoso di un INSERT su quella tabella.

Queste istruzioni possono assumere molte forme, ma se si limita la discussione alle loro forme "di base" che implicano un singolo record, la parte più grande del costo sarà solitamente dedicata alla modifica degli indici. Ogni campo indicizzato che viene modificato durante un UPDATE implicherebbe in genere due operazioni di base (eliminare la vecchia chiave e aggiungere la nuova chiave) mentre l'INSERT ne richiederebbe una (aggiungere la nuova chiave). Ovviamente, un indice cluster aggiungerebbe altre dinamiche come problemi di blocco, isolamento delle transazioni, ecc. Quindi, in definitiva, il confronto tra queste affermazioni in senso generale non è realmente possibile e richiederebbe probabilmente il benchmarking di affermazioni specifiche se in realtà importava.

In genere, tuttavia, ha senso utilizzare semplicemente l'istruzione corretta e non preoccuparsi poiché non è in genere un'opzione per scegliere tra un UPDATE e un INSERT.

Answer 3

Dipende. Se l'aggiornamento non richiede modifiche della chiave, è probabile che ciò comporterà solo un costo di ricerca e quindi probabilmente costa meno di un inserto, a meno che il database non sia organizzato come un heap.

Questo è l'unico pensiero che posso affermare, perché le prestazioni dipendono molto dall'organizzazione del database utilizzata.

Se ad esempio si utilizza MyISAM che suppongo organizzato come un isam, l'inserimento dovrebbe essere generalmente lo stesso in termini di accessi in lettura del database, ma richiederà alcune operazioni di scrittura aggiuntive.

Answer 4

Non è possibile confrontare un INSERIMENTO e un AGGIORNAMENTO in generale. Dacci un esempio (con la definizione dello schema) e spiegheremo quale costa di più e perché. Inoltre, puoi compere un INSERT concreto e un UPDATE controllando il loro piano e il tempo di esecuzione.

Alcune regole di pollice però:

• se aggiornare solo un solo campo, che non è indicizzato e si aggiornano solo record e si utilizza rowid chiave/primaria di trovare quel record, allora questo aggiornamento avrà un costo inferiore a
• un INSERIMENTO, che influirà anche su una sola riga, sebbene questa riga abbia molti campi indicizzati non vincolati a zero; e tutti gli indici devono essere mantenuti (ad es. aggiungere una nuova foglia)

Answer 5

Su Sybase/SQL Server un aggiornamento che ha effetto su una colonna con un indice di sola lettura è internamente sostituito da una cancellazione e quindi un inserto, quindi questo è ovviamente più lento di inserire. Non conosco l'implementazione per altri motori, ma penso che questa sia una strategia comune almeno quando sono coinvolti gli indici. Ora per le tabelle senza indici (o per le richieste di aggiornamento che non implicano alcun indice) suppongo che ci siano casi in cui l'aggiornamento può essere più veloce, a seconda della struttura della tabella.

Answer 6

La risorsa chiave qui è l'accesso al disco (IOPS per essere precisi) e dovremmo valutare quali risultano almeno in questo.

D'accordo con gli altri su come sia impossibile dare una risposta generica ma alcuni pensieri per guidarti nella giusta direzione, assumere un semplice archivio di valori-chiave e la chiave è indicizzata. L'inserimento sta inserendo una nuova chiave e l'aggiornamento sta aggiornando il valore di una chiave esistente.

In questo caso (caso molto comune), l'aggiornamento sarebbe più rapido dell'inserimento poiché l'aggiornamento implica una ricerca indicizzata e la modifica di un valore esistente senza toccare l'indice. Si può presumere che sia un disco letto per ottenere i dati e possibilmente una scrittura su disco. D'altra parte l'inserimento implicherebbe due scritture su disco uno per l'indice, uno per i dati. Ma l'altro costo nascosto è la suddivisione del nodo btree e la creazione di un nuovo nodo che avverrebbe in background mentre l'inserimento porta a un maggiore accesso al disco in media.

Answer 7

Se si prevede di eseguire una elaborazione di grandi dimensioni (come la valutazione o la fatturazione per una società cellulare), questa domanda ha un enorme impatto sulle prestazioni del sistema.

L'esecuzione di aggiornamenti su larga scala rispetto a molti nuovi tavoli e indici ha dimostrato di ridurre il modulo di fatturazione aziendale da 26 ore a 1 ora!

Ho provato su 2 milioni di record per 100.000 clienti. Prima ho creato la tabella di fatturazione e poi ogni chiamata di riepilogo del cliente, ho aggiornato la tabella di fatturazione con la durata, il prezzo, lo sconto .. un totale di 10 campi.

Nella seconda opzione ho creato 4 fasi. Ogni fase legge le tabelle precedenti, crea l'indice (dopo l'inserimento della tabella completato) e utilizza: "insert in from select .." Ho creato la tabella successiva per la fase successiva.

Sintesi Anche se la seconda alternativa richiede molto più spazio su disco (tutti i punti di vista e le tabelle temporanee cancellato alla fine) ci sono 3 principali vantaggi di questa opzione: 1. E 'stato 4 il tempo più veloce di opzione 1. 2. Nel caso ci fosse un problema nel mezzo del processo, potevo avviare il processo dal punto in cui non era riuscito, poiché tutte le tabelle per l'inizio della fase erano pronte e il processo poteva riprendere da questo punto. Se il processo non riesce a implementare la prima opzione, sarà necessario avviare nuovamente tutto il processo. 3. Ciò ha reso lo sviluppo e il controllo della qualità molto più veloce in quanto potevano funzionare parallelamente allo .