Las TECLAS DESACTIVADAS de MySqlDump no tienen efecto en la importación

Tengo un seguimiento de mi pregunta anterior sobre la velocidad de importación con Inno-Tables (¡sorpresa!).

Escenario
Intento importar un volcado de base de datos grande * en mi máquina de desarrollo local en un tiempo razonable. Tenemos muchos KEYcorreos adjuntos a las tablas que han resultado ser un cuello de botella pero que siguen siendo importantes para nuestro sistema en vivo.

Mi enfoque después de hacer la pregunta anterior fue eliminar las KEY ...declaraciones de volcado, importar y volver a agregar claves.

Sin embargo, a menudo me encuentro editando un volcado actual para importarlo localmente y me topé con estos divertidos "comentarios" (The disable/enable keys-lines)

--
-- 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;

Pero, de hecho, estos "comentarios" son declaraciones condicionales de MySql

Eso fue una novedad para mí, pero bueno, dado el formulario de salida, mysql --versiontodo me parece bien: mysql Ver 14.14 Distrib 5.5.38, for debian-linux-gnu (x86_64) using readline 6.3

Lo que supongo
La mesa está bloqueada (bien, solo soy yo en el dev mashine). Luego, las claves definidas en el esquema de la tabla se deshabilitan, se importan los datos y se habilitan las claves.
Por lo tanto, durante la fase de "inserción de datos", no se debe perder el tiempo en las claves, sino examinarlas después de insertar todos los datos.

KEY 'foo' (foo)'Pensaría que este es el mismo comportamiento que si elimino todas las líneas del volcado, importo el volcado y ejecuto un script ADD KEY 'foo' ...después.

Lo que observo
Es mucho más rápido eliminar manualmente las claves, importar y volver a agregar claves y luego confiar en las DISABLE KEYSdeclaraciones condicionales creadasmysqldump

Edición manual de dump + mysql import + add keys = 15 + 8 + 8 ≈ 30min
Plain mysql import: abandonado, (solo me pagan por 8 horas / día> :))

No puedo evitar pensar que me falta algo muy fundamental aquí (o la base de datos me está controlando).

No puede confiar en DISABLE KEYS;y ENABLE KEYS;para InnoDB porque no está implementado en el motor de almacenamiento de InnoDB. Corriendo ALTER TABLE ... DISABLE KEYS;y ALTER TABLE ... ENABLE KEYS;fueron diseñados para MyISAM. Como dice en la documentación de MySQL paraALTER TABLE :

Si usa ALTER TABLE en una tabla MyISAM, todos los índices no únicos se crean en un lote separado (como en REPAIR TABLE). Esto debería hacer que ALTER TABLE sea mucho más rápido cuando tiene muchos índices.

Para las tablas MyISAM, la actualización de claves se puede controlar explícitamente. Use ALTER TABLE ... DISABLE KEYS para decirle a MySQL que deje de actualizar índices no únicos. Luego use ALTER TABLE ... ENABLE KEYS para volver a crear índices faltantes. MyISAM hace esto con un algoritmo especial que es mucho más rápido que insertar llaves una por una, por lo que deshabilitar las teclas antes de realizar operaciones de inserción masiva debería acelerar considerablemente. El uso de ALTER TABLE ... DISABLE KEYS requiere el privilegio INDEX además de los privilegios mencionados anteriormente.

Si bien los índices no únicos están deshabilitados, se ignoran para las declaraciones como SELECT y EXPLAIN que de otro modo las usarían.

Nunca se hace mención de InnoDB en contexto con ALTER TABLE ... DISABLE/ENABLE KEYS;

Incluso si se ejecuta ALTER TABLE ... DISABLE KEYS;contra una tabla InnoDB, genera una advertencia:

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>

Por eso no hay afecto. Recuerde que @jynus mencionó lo mismo en su respuesta en el punto 7 .

Tenga en cuenta también que MyISAM mantiene datos e índices en dos archivos separados (.MYD para datos, .MYI para índices), por lo que sería trivial deshabilitar y habilitar índices. InnoDB mantiene la CLAVE PRIMARIA y los datos de fila en las mismas páginas de InnoDB (a través del índice agrupado). Los índices secundarios llevarán la CLAVE PRIMARIA como un archivo adjunto a cada entrada secundaria de hoja de índice . Dado que los datos e índices se entrelazan a través del índice agrupado, nadie ha, hasta el momento, intentado poner en práctica DISABLE KEYSy ENABLE KEYSen InnoDB.