engine datos crear cambiar mysql optimization innodb myisam

mysql - datos - Acelerar la conversión de MyISAM a InnoDB



myisam to innodb (4)

Tengo una tabla MySIS de 1.5 GB MyISAM (datos de 1.0 GB, índices de 0.5 GB) en producción que estoy a punto de convertir en InnoDB.

Como la tabla se utiliza en producción, me gustaría que el tiempo de inactividad sea lo más corto posible.

Mis preguntas:

  • Las opciones de configuración de MySQL deben ajustarse para acelerar ALTER TABLE table_name ENGINE=InnoDB; ?

  • ¿Qué otros trucos se pueden usar para acelerar la conversión de una tabla de base de datos de producción de MyISAM a InnoDB?


El uso de pt-online-schema-change haría que su problema sea irrelevante. pt-online-schema-change es una herramienta de línea de comandos diseñada por Percona (posiblemente la consultora de MySQL más importante del mundo) para resolver este problema. Le permite llevar a cabo instrucciones ALTER en cualquier tabla sin bloquear las lecturas O las escrituras, lo que probablemente sea su objetivo REAL si dice que está tratando de acelerar esta conversión en producción.

Después de instalar Percona Toolkit, simplemente ejecutaría el siguiente comando en su shell O / S:

$ pt-online-schema-change h=your_host.com,t=your_db.your_target_table --alter "ENGINE=InnoDB"


La tabla solo será inaccesible para escrituras; Las lecturas continuarán accediendo a la antigua tabla MyISAM durante la duración de ALTER.

En serio, la reconstrucción de una tabla 1.5G no debería llevar mucho tiempo, si su aplicación no puede tolerar esa cantidad de tiempo de inactividad, ya debe tener instalado un sistema de alta disponibilidad que puede usar para hacer esto. Presumiblemente, su equipo de soporte técnico puede enviar un aviso para informar a los usuarios sobre el tiempo de inactividad y advertirle lo suficiente, lo hará en un momento tranquilo del día / semana (normalmente, el domingo por la mañana es un buen momento, pero puede variar si tienes muchos clientes en paises musulmanes)

Puede averiguar cuánto tiempo tardará en ejecutarse en la tabla con el mismo tamaño de datos en su sistema de no producción con la misma configuración y especificaciones, que sin duda tiene para las pruebas de rendimiento.


Si busca una solución rápida (aunque un poco baja), puede simplemente exportar los datos a un archivo de texto (a través de mysqldump), cambiar el tipo de tabla a InnoDB en el archivo de texto resultante y luego volver a importar los datos.

Dicho esto, deberías probar esto importando en una base de datos diferente para asegurarte de que no haya problemas.


  • Configuración de un gran innodb_buffer_pool_size (2GB o más)
  • Lea previamente sus viejos archivos de datos / índice myisam usando comandos de shell
  • aumentar innodb_log_file_size (256 MB)
  • Realice la modificación de la tabla en X hilos paralelos, donde X es la cantidad de núcleos de CPU en su servidor
  • otros ajustes menores solo para conversión (innodb_doublewrite = 0, innodb_flush_log_at_trx_commit = 0)

configurar innodb_buffer_pool_size lo más alto posible es la forma típica de acelerar la creación de tablas innodb: parece que su conjunto de datos podría encajar dentro de un grupo de búfer innodb de 2GB, por lo que cualquier servidor de 64 bits decente debería permitirlo. alter table type = innodb es también más rápido que la solución dump + reimport, y es fácil de ejecutar en paralelo.

También asegúrese de haber aumentado el innodb_log_file_size del valor predeterminado de 5Mb a 128 o 256MB. Tenga cuidado con eso, y necesita un cierre limpio + borrado del antiguo archivo_bile *.

Si su servidor tiene algo así como 8 GB de memoria RAM, y si ejecuta una versión de mysql de 64 bits, sugeriría una innodb_buffer_pool de 2 GB, e incluso puede leer previamente los antiguos archivos MYD y MYI antes de cerrar para el tiempo de inactividad, de modo que estén en el servidor. Caché de la página del sistema operativo cuando comienza el trabajo real.

Si también va por los ajustes menores, tenga en cuenta que debe deshacerlos después de la conversión (otro pequeño tiempo de inactividad) para que sus datos estén seguros, aunque dudo que valgan la pena para un conjunto de datos tan pequeño.

Buena suerte.