Ik heb een beetje met dit concept geëxperimenteerd bij een vorige baan, waar we een snelle methode nodig hadden om schema's tussen MySQL-servers te kopiëren.
Er is inderdaad een prestatieoverhead wanneer u invoegt in tabellen met secundaire indexen. Invoegingen moeten de geclusterde index (ook wel de tabel genoemd) bijwerken en ook secundaire indexen bijwerken. Hoe meer indexen een tabel heeft, hoe meer overhead het veroorzaakt voor invoegingen.
InnoDB heeft een functie genaamd de veranderbuffer wat een beetje helpt door indexupdates uit te stellen, maar ze moeten uiteindelijk worden samengevoegd.
Invoegingen aan een tabel zonder secundaire indexen zijn sneller, dus het is verleidelijk om het maken van een index uit te stellen tot nadat uw gegevens zijn geladen, zoals u beschrijft.
Percona Server, een tak van MySQL, experimenteerde met een mysqldump --optimize-keys keuze. Wanneer u deze optie gebruikt, verandert het de uitvoer van mysqldump om CREATE TABLE zonder indexen te hebben, dan INSERT alle gegevens, dan ALTER TABLE om de indexen toe te voegen nadat de gegevens zijn geladen. Zie https://www.percona.com/doc/ percona-server/LATEST/management/innodb_expanded_fast_index_creation.html
Maar in mijn ervaring was de netto prestatieverbetering klein. Het duurt nog even om veel rijen in te voegen, zelfs voor tabellen zonder indexen. Dan moet het herstel een ALTER TABLE uitvoeren om de indexen te bouwen. Bij een grote tafel duurt dit even. Als je de tijd van INSERT's meet plus de extra tijd om indexen te maken, is het slechts een paar procent (lage enkele cijfers) sneller dan wanneer je op de traditionele manier in een tabel met indexen invoegt.
Een ander voordeel van het maken van indexen na verwerking is dat de indexen compacter worden opgeslagen, dus als u schijfruimte wilt besparen, is dat een betere reden om deze techniek te gebruiken.
Ik vond het veel gunstiger voor de prestaties om te herstellen door verschillende tabellen parallel te laden .
- De nieuwe MySQL 8.0-tool mysqlpump ondersteunt multi-threaded dump.
- De open-source tool mydumper
ondersteunt multi-threaded dump, en heeft ook een multi-threaded restore tool, genaamd
myloader. Het ergste nadeel van mydumper/myloader is dat de documentatie vrijwel onbestaande is, dus je moet een onverschrokken krachtige gebruiker zijn om erachter te komen hoe je het moet gebruiken.
Een andere strategie is om mysqldump --tab . te gebruiken om CSV-bestanden te dumpen in plaats van SQL-scripts. CSV-bestanden in bulk laden is veel sneller dan het uitvoeren van SQL-scripts om de gegevens te herstellen. Welnu, het dumpt een SQL-bestand voor de tabeldefinitie en een CSV voor de te importeren gegevens. Het maakt aparte bestanden voor elke tabel. U moet de tabellen handmatig opnieuw maken door alle SQL-bestanden te laden (dit is snel) en vervolgens mysqlimport
om de CSV-gegevensbestanden te laden. De tool mysqlimport heeft zelfs een --use-threads optie voor parallelle uitvoering.
Test zorgvuldig met verschillende aantallen parallelle draden. Mijn ervaring is dat 4 threads het beste is. Met meer parallellisme wordt InnoDB een knelpunt. Maar uw ervaring kan anders zijn, afhankelijk van de versie van MySQL en de prestatiecapaciteit van uw serverhardware.
De snelste herstelmethode is wanneer u een fysieke back-uptool gebruikt, de meest populaire is Percona XtraBackup . Dit zorgt voor snelle back-ups en nog snellere restores. De back-upbestanden zijn letterlijk klaar om op hun plaats te worden gekopieerd en gebruikt als live tablespace-bestanden. Het nadeel is dat u uw MySQL-server moet afsluiten om het herstel uit te voeren.