Du skal helt sikkert vælge din tilgang baseret på motortypen... optimering til MyISAM eller til InnoDB .
Vi kørte for nylig en benchmark, der sammenlignede forskellige måder at indsætte data på og målte tiden fra før indsættelse og indtil alle indekser er fuldt gendannet. Det var på et tomt bord, men vi brugte op til 10 millioner rækker.
MyISAM med LOAD DATA INFILE og ALTER TABLE ... ENABLE/DISABLE KEYS vandt hænder ned i vores test (på et Windows 7-system, MySQL 5.5.27 - nu prøver vi det på et Linux-system).
AKTIVER og DEAKTIVER NØGLER virker ikke for InnoDB, det er kun MyISAM. For InnoDB skal du bruge SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS = 0; SET UNIQUE_CHECKS = 0; hvis du er sikker på, at dine data ikke indeholder dubletter (glem ikke at indstille dem til 1 efter upload er fuldført).
Jeg tror ikke, du behøver OPTIMIZE TABLE efter en masseindsættelse - MySQL rækker er ordnet efter indsættelse, og indekset genopbygges alligevel. Der er ingen "ekstra fragmentering" ved at lave en masseindsættelse.
Kommenter gerne, hvis jeg lavede faktuelle fejl.
OPDATERING: Ifølge vores nyere og fuldstændige testresultater er rådet om at DEAKTIVERE/AKTIVERE nøgler forkert.
En kollega fik et program til at køre flere forskellige tests - en tabel med InnoDB / MyISAM forudfyldt og tom, valg- og indsættelseshastigheder med LOAD DATA LOCAL , INSERT INTO , REPLACE INTO og UPDATE , på "tætte" og "fragmenterede" tabeller (jeg er ikke helt sikker på hvordan, jeg tror det var i stil med DELETE FROM ... ORDER BY RAND() LIMIT ... med et fast seed, så det stadig er sammenligneligt) og aktiverede og deaktiverede indekser.
Vi testede det med mange forskellige MySQL-versioner (5.0.27, 5.0.96, 5.1.something, 5.5.27, 5.6.2) på Windows og Linux (dog ikke de samme versioner på begge OS). MyISAM vandt kun, når bordet var tomt. InnoDB var hurtigere, når data allerede var til stede og klarede sig generelt bedre (bortset fra hdd-plads - MyISAM er mindre på disken).
Alligevel, for virkelig at drage fordel af det, skal du teste det selv - med forskellige versioner, forskellige konfigurationsindstillinger og en masse tålmodighed - især med hensyn til mærkelige uoverensstemmelser (5.0.97 var meget hurtigere end 5.5.27 med samme konfiguration - vi søger stadig efter årsagen). Det, vi fandt, var at DISABLE KEYS og ENABLE KEYS er næsten værdiløse og nogle gange skadelige, hvis du ikke starter med et tomt bord.