Experimenté un poco con este concepto en un trabajo anterior, donde necesitábamos un método rápido para copiar esquemas entre servidores MySQL.
De hecho, hay una sobrecarga de rendimiento cuando se inserta en tablas que tienen índices secundarios. Las inserciones deben actualizar el índice agrupado (también conocido como la tabla) y también actualizar los índices secundarios. Cuantos más índices tiene una tabla, más gastos genera para las inserciones.
InnoDB tiene una función llamada cambio de búfer lo que ayuda un poco al posponer las actualizaciones del índice, pero eventualmente deben fusionarse.
Las inserciones en una tabla sin índices secundarios son más rápidas, por lo que es tentador tratar de diferir la creación del índice hasta después de que se carguen los datos, como usted describe.
Percona Server, una rama de MySQL, experimentó con un mysqldump --optimize-keys opción. Cuando usa esta opción, cambia la salida de mysqldump para tener CREAR TABLA sin índices, luego INSERTAR todos los datos, luego ALTERAR TABLA para agregar los índices después de cargar los datos. Consulte https://www.percona.com/doc/ servidor-percona/ÚLTIMO/management/innodb_expanded_fast_index_creation.html
Pero en mi experiencia, la mejora neta en el rendimiento fue pequeña. Todavía lleva un tiempo insertar muchas filas, incluso para tablas sin índices. Luego, la restauración debe ejecutar ALTER TABLE para generar los índices. Esto toma un tiempo para una mesa grande. Cuando cuenta el tiempo de INSERT más el tiempo adicional para crear índices, es solo unos pocos porcentajes (un solo dígito bajo) más rápido que insertar de la manera tradicional, en una tabla con índices.
Otro beneficio de esta creación de índices de posprocesamiento es que los índices se almacenan de forma más compacta, por lo que si necesita ahorrar espacio en disco, esa es una mejor razón para usar esta técnica.
Descubrí que era mucho más beneficioso para el rendimiento restaurar cargando varias tablas en paralelo .
- La nueva herramienta MySQL 8.0 mysqlpump admite volcado de subprocesos múltiples.
- La herramienta de código abierto mydumper
admite el volcado de subprocesos múltiples y también tiene una herramienta de restauración de subprocesos múltiples, llamada
myloader. El peor inconveniente de mydumper/myloader es que la documentación es prácticamente inexistente, por lo que debe ser un usuario avanzado e intrépido para descubrir cómo ejecutarlo.
Otra estrategia es usar mysqldump --tab para volcar archivos CSV en lugar de scripts SQL. La carga masiva de archivos CSV es mucho más rápida que ejecutar scripts SQL para restaurar los datos. Bueno, descarga un archivo SQL para la definición de la tabla y un CSV para importar los datos. Crea archivos separados para cada tabla. Debe recrear manualmente las tablas cargando todos los archivos SQL (esto es rápido) y luego usar mysqlimport
para cargar los archivos de datos CSV. La herramienta mysqlimport incluso tiene un --use-threads opción para ejecución paralela.
Pruebe cuidadosamente con diferentes números de hilos paralelos. Mi experiencia es que 4 hilos es lo mejor. Con mayor paralelismo, InnoDB se convierte en un cuello de botella. Pero su experiencia puede ser diferente, según la versión de MySQL y la capacidad de rendimiento del hardware de su servidor.
El método de restauración más rápido de todos es cuando usa una herramienta de respaldo físico, el más popular es Percona XtraBackup . Esto permite copias de seguridad rápidas e incluso restauraciones más rápidas. Los archivos respaldados están literalmente listos para copiarse en su lugar y usarse como archivos de tablespace en vivo. La desventaja es que debe apagar su servidor MySQL para realizar la restauración.
