I DISABLE KEYS di MySqlDump non hanno alcun effetto sull'importazione

Ho seguito la mia domanda precedente sulla velocità di importazione con Inno-Tables (sorpresa!).

Scenario
Provo a importare alcuni grandi * dump di database sulla mia macchina di sviluppo locale in tempi ragionevoli. Abbiamo molti KEYs collegati ai tavoli che si sono rivelati un collo di bottiglia ma sono ancora importanti per il nostro sistema live.

Il mio approccio dopo aver posto la domanda sopra è stato quello di eliminare le KEY ...istruzioni dal dump, importare e aggiungere nuovamente le chiavi.

Tuttavia mi trovo spesso a modificare un dump corrente per importarlo localmente e mi sono imbattuto in questi divertenti "commenti" (Le disable/enable keyslinee)

--
-- Dumping data for table `monster`
--

LOCK TABLES `monster` WRITE;
/*!40000 ALTER TABLE `monster` DISABLE KEYS */;
INSERT … INSERT … INSERT
/*!40000 ALTER TABLE `monster` ENABLE KEYS */;
UNLOCK TABLES;

Ma in realtà questi "commenti" sono dichiarazioni MySql condizionate

Questa è stata una novità per me, ma va bene, dato il modulo di output, mysql --versiontutto mi sembra perfetto: mysql Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.3

Cosa presumo
Il tavolo è bloccato (va bene, sono solo io sul mashine di sviluppo). Quindi le chiavi come definite nello schema della tabella sono disabilitate, i dati vengono importati, le chiavi sono abilitate.
Quindi durante la fase di "inserimento dei dati" non dovrebbe esserci tempo perso sulle chiavi ma piuttosto esaminato dopo l'inserimento di tutti i dati.

Penserei che questo sia lo stesso comportamento che se KEY 'foo' (foo)'eliminassi tutte le righe dal dump, importassi il dump ed eseguissi uno script in ADD KEY 'foo' ...seguito.

Quello che osservo
È molto più veloce eliminare manualmente le chiavi, importare e aggiungere nuovamente le chiavi e fare affidamento su DISABLE KEYSistruzioni condizionali create da memysqldump

Modifica manuale di dump + importazione mysql + aggiunta di chiavi = 15 + 8 + 8 ≈ 30min
Importazione mysql semplice: rinuncia, (mi pagano solo 8 ore al giorno> :))

Non posso fare a meno di pensare che mi manchi qualcosa di fondamentale qui (o il database mi sta trollando).

Non è possibile fare affidamento su DISABLE KEYS;e ENABLE KEYS;per InnoDB perché non è implementato nel motore di archiviazione InnoDB. In esecuzione ALTER TABLE ... DISABLE KEYS;e ALTER TABLE ... ENABLE KEYS;sono stati progettati per MyISAM. Come indicato nella documentazione di MySQL perALTER TABLE :

Se si utilizza ALTER TABLE su una tabella MyISAM, tutti gli indici non unici vengono creati in un batch separato (come per REPAIR TABLE). Ciò dovrebbe rendere ALTER TABLE molto più veloce quando si hanno molti indici.

Per le tabelle MyISAM, l'aggiornamento delle chiavi può essere controllato esplicitamente. Usa ALTER TABLE ... DISABLE KEYS per dire a MySQL di interrompere l'aggiornamento degli indici non unici. Quindi utilizzare ALTER TABLE ... ENABLE KEYS per ricreare gli indici mancanti. MyISAM lo fa con un algoritmo speciale che è molto più veloce dell'inserimento di chiavi uno per uno, quindi disabilitare le chiavi prima di eseguire operazioni di inserimento in blocco dovrebbe dare una notevole velocità. L'uso di ALTER TABLE ... DISABLE KEYS richiede il privilegio INDEX oltre ai privilegi menzionati in precedenza.

Mentre gli indici non unici sono disabilitati, vengono ignorati per istruzioni come SELECT ed EXPLAIN che altrimenti li userebbero.

InnoDB non viene mai menzionato nel contesto di ALTER TABLE ... DISABLE/ENABLE KEYS;

Anche se si esegue ALTER TABLE ... DISABLE KEYS;su una tabella InnoDB, viene generato un avviso:

mysql> show create table mytimes\G
*************************** 1. row ***************************
       Table: mytimes
Create Table: CREATE TABLE `mytimes` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `totalTime` int(11) NOT NULL,
  `totalTimeDesc` varchar(128) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

mysql> alter table mytimes disable keys;
Query OK, 0 rows affected, 1 warning (0.01 sec)

mysql> show warnings;
+-------+------+-------------------------------------------------------------+
| Level | Code | Message                                                     |
+-------+------+-------------------------------------------------------------+
| Note  | 1031 | Table storage engine for 'mytimes' doesn't have this option |
+-------+------+-------------------------------------------------------------+
1 row in set (0.00 sec)

mysql>

Ecco perché non c'è alcun effetto. Ricorda che @jynus ha menzionato la stessa cosa nella sua risposta nel punto 7 .

Tieni presente anche che MyISAM mantiene i dati e gli indici in due file separati (.MYD per i dati, .MYI per gli indici), quindi sarebbe banale disabilitare e abilitare gli indici. InnoDB conserva il PRIMARY KEY e i dati delle righe nelle stesse pagine InnoDB (tramite l'indice cluster). Gli indici secondari porteranno la CHIAVE PRIMARIA come allegato ad ogni voce foglia dell'indice secondario . Poiché i dati e gli indici sono intrecciati tramite l'indice cluster, nessuno ha ancora tentato di implementare DISABLE KEYSe ENABLE KEYSin InnoDB.