Ho sperimentato un po' questo concetto in un lavoro passato, in cui avevamo bisogno di un metodo veloce per copiare gli schemi tra i server MySQL.
C'è infatti un sovraccarico di prestazioni quando si inseriscono in tabelle che hanno indici secondari. Gli inserti devono aggiornare l'indice cluster (ovvero la tabella) e aggiornare anche gli indici secondari. Più indici ha una tabella, maggiore sarà il sovraccarico per gli inserimenti.
InnoDB ha una funzione chiamata change buffer il che aiuta un po' posticipando gli aggiornamenti dell'indice, ma alla fine devono essere uniti.
Gli inserimenti in una tabella senza indici secondari sono più veloci, quindi si è tentati di rinviare la creazione dell'indice fino a quando i dati non sono stati caricati, come descrivi.
Percona Server, un ramo di MySQL, ha sperimentato un mysqldump --optimize-keys opzione. Quando usi questa opzione, cambia l'output di mysqldump per avere CREATE TABLE senza indici, quindi INSERT tutti i dati, quindi ALTER TABLE per aggiungere gli indici dopo che i dati sono stati caricati. Vedi https://www.percona.com/doc/ percona-server/LATEST/management/innodb_expanded_fast_index_creation.html
Ma nella mia esperienza, il miglioramento netto delle prestazioni è stato piccolo. Ci vuole ancora del tempo per inserire molte righe, anche per le tabelle senza indici. Quindi il ripristino deve eseguire un ALTER TABLE per creare gli indici. Ci vuole un po' per un tavolo grande. Quando si contano il tempo di INSERT più il tempo extra per creare gli indici, sono solo alcune percentuali (bassa cifra singola) più veloci rispetto all'inserimento nel modo tradizionale, in una tabella con indici.
Un altro vantaggio di questa creazione di indici di post-elaborazione è che gli indici sono archiviati in modo più compatto, quindi se è necessario risparmiare spazio su disco, questo è un motivo migliore per utilizzare questa tecnica.
Ho trovato molto più vantaggioso per le prestazioni ripristinare caricando più tabelle in parallelo .
- Il nuovo strumento MySQL 8.0 mysqlpump supporta il dump multi-thread.
- Lo strumento open source mydumper
supporta il dump multi-thread e ha anche uno strumento di ripristino multi-thread, chiamato
myloader. Il peggior svantaggio di mydumper/myloader è che la documentazione è praticamente inesistente, quindi devi essere un intrepido utente esperto per capire come eseguirlo.
Un'altra strategia consiste nell'usare mysqldump --tab per eseguire il dump di file CSV invece di script SQL. Il caricamento in blocco di file CSV è molto più veloce dell'esecuzione di script SQL per ripristinare i dati. Bene, scarica un file SQL per la definizione della tabella e un CSV per i dati da importare. Crea file separati per ogni tabella. Devi ricreare manualmente le tabelle caricando tutti i file SQL (questo è veloce), quindi utilizzare mysqlimport
per caricare i file di dati CSV. Lo strumento mysqlimport ha anche un --use-threads opzione per l'esecuzione parallela.
Testare attentamente con diversi numeri di fili paralleli. La mia esperienza è che 4 thread sono i migliori. Con un maggiore parallelismo, InnoDB diventa un collo di bottiglia. Ma la tua esperienza potrebbe essere diversa, a seconda della versione di MySQL e della capacità delle prestazioni dell'hardware del tuo server.
Il metodo di ripristino più veloce di tutti è quando si utilizza uno strumento di backup fisico, il più popolare è Percona XtraBackup . Ciò consente backup rapidi e ripristini ancora più rapidi. I file di backup sono letteralmente pronti per essere copiati in posizione e utilizzati come file tablespace attivi. Lo svantaggio è che è necessario spegnere il server MySQL per eseguire il ripristino.
