Du måste definitivt välja ditt tillvägagångssätt baserat på motortypen... optimerar för MyISAM eller för InnoDB .
Vi körde nyligen ett benchmark som jämförde olika sätt att infoga data och mätte tiden från innan införandet och tills alla index är helt återställda. Det låg på ett tomt bord, men vi använde upp till 10 miljoner rader.
MyISAM med LOAD DATA INFILE och ALTER TABLE ... ENABLE/DISABLE KEYS vann helt klart i vårt test (på ett Windows 7-system, MySQL 5.5.27 - nu provar vi det på ett Linux-system).
AKTIVERA och AVAKTIVERA NYCKLAR fungerar inte för InnoDB, det är bara MyISAM. För InnoDB, använd SET AUTOCOMMIT = 0; SET FOREIGN_KEY_CHECKS = 0; SET UNIQUE_CHECKS = 0; om du är säker på att dina data inte innehåller dubbletter (glöm inte att ställa in dem på 1 efter att uppladdningen är klar).
Jag tror inte att du behöver OPTIMIZE TABLE efter en bulkinsert - MySQL-rader ordnas genom insättning och indexet byggs om ändå. Det finns ingen "extra fragmentering" genom att göra en massinsättning.
Kommentera gärna om jag gjort faktafel.
UPPDATERING: Enligt våra nyare och fullständiga testresultat är rådet att INAKTIVERA/AKTIVERA nycklar fel.
En kollega lät ett program köra flera olika tester - en tabell med InnoDB / MyISAM ifylld och tom, urvals- och infogningshastigheter med LOAD DATA LOCAL , INSERT INTO , REPLACE INTO och UPDATE , på "täta" och "fragmenterade" tabeller (jag är inte riktigt säker på hur, jag tror att det var i stil med DELETE FROM ... ORDER BY RAND() LIMIT ... med ett fast seed så det fortfarande är jämförbart) och aktiverade och inaktiverade index.
Vi testade det med många olika MySQL-versioner (5.0.27, 5.0.96, 5.1.something, 5.5.27, 5.6.2) på Windows och Linux (inte samma versioner på båda operativsystemen dock). MyISAM vann bara när bordet var tomt. InnoDB var snabbare när data redan fanns och fungerade generellt bättre (förutom hdd-utrymme - MyISAM är mindre på disken).
Ändå, för att verkligen dra nytta av det måste du testa det själv - med olika versioner, olika konfigurationsinställningar och mycket tålamod - speciellt när det gäller konstiga inkonsekvenser (5.0.97 var mycket snabbare än 5.5.27 med samma konfiguration - vi letar fortfarande efter orsaken). Vad vi hittade var att DISABLE KEYS och ENABLE KEYS är nästan värdelösa och ibland skadliga om du inte börjar med ett tomt bord.