Jag experimenterade lite med det här konceptet på ett tidigare jobb, där vi behövde en snabb metod för att kopiera scheman mellan MySQL-servrar.
Det finns verkligen en prestandaoverhead när du infogar i tabeller som har sekundära index. Infogar måste uppdatera det klustrade indexet (alias tabellen) och även uppdatera sekundära index. Ju fler index en tabell har, desto mer omkostnader orsakar den för insättningar.
InnoDB har en funktion som heter ändringsbuffert vilket hjälper lite genom att skjuta upp indexuppdateringar, men de måste slås samman så småningom.
Infogning i en tabell utan sekundära index går snabbare, så det är frestande att försöka skjuta upp indexskapandet tills efter att din data har laddats, som du beskriver.
Percona Server, en gren av MySQL, experimenterade med en mysqldump --optimize-keys alternativ. När du använder det här alternativet ändrar det utdata från mysqldump till att ha CREATE TABLE utan index, sedan INSERT all data och sedan ALTER TABLE för att lägga till indexen efter att data har laddats. Se https://www.percona.com/doc/ percona-server/SENESTE/management/innodb_expanded_fast_index_creation.html
Men enligt min erfarenhet var nettoförbättringen i prestanda liten. Det tar fortfarande ett tag att infoga många rader, även för tabeller utan index. Sedan måste återställningen köra en ALTER TABLE för att bygga indexen. Detta tar ett tag för ett stort bord. När du räknar tiden för INSERT plus den extra tiden för att bygga index, är det bara några (låga ensiffriga) procent snabbare än att infoga på traditionellt sätt, i en tabell med index.
En annan fördel med att skapa index efter bearbetning är att indexen lagras mer kompakt, så om du behöver spara diskutrymme är det en bättre anledning att använda den här tekniken.
Jag tyckte att det var mycket mer fördelaktigt för prestanda att återställa genom att ladda flera tabeller parallellt .
- Det nya MySQL 8.0-verktyget mysqlpump stöder flertrådig dump.
- Öppen källkodsverktyget mydumper
stöder multi-threaded dump, och har även ett multi-threaded återställningsverktyg, kallat
myloader. Den värsta nackdelen med mydumper/myloader är att dokumentationen är praktiskt taget obefintlig, så du måste vara en orädd superanvändare för att ta reda på hur du kör den.
En annan strategi är att använda mysqldump --tab att dumpa CSV-filer istället för SQL-skript. Bulkladdning av CSV-filer är mycket snabbare än att köra SQL-skript för att återställa data. Tja, den dumpar en SQL-fil för tabelldefinitionen och en CSV för data som ska importeras. Det skapar separata filer för varje tabell. Du måste manuellt återskapa tabellerna genom att ladda alla SQL-filer (detta går snabbt), och sedan använda mysqlimport
för att ladda CSV-datafilerna. Mysqlimport-verktyget har till och med en --use-threads alternativ för parallell exekvering.
Testa noggrant med olika antal parallella gängor. Min erfarenhet är att 4 trådar är bäst. Med större parallellitet blir InnoDB en flaskhals. Men din upplevelse kan vara annorlunda, beroende på versionen av MySQL och din servermaskinvaras prestandakapacitet.
Den snabbaste återställningsmetoden av alla är när du använder ett fysiskt säkerhetskopieringsverktyg, den mest populära är Percona XtraBackup . Detta möjliggör snabba säkerhetskopieringar och ännu snabbare återställningar. De säkerhetskopierade filerna är bokstavligen redo att kopieras på plats och användas som live tablespace-filer. Nackdelen är att du måste stänga av din MySQL-server för att utföra återställningen.