Tamaño de transacción de MySQL: ¿qué tan grande es demasiado grande?

Tengo un proceso de importación que se ejecuta de vez en cuando y quiero que sea un tipo de trato 'todo o nada', también conocido como: una transacción.

Hay muchos aspectos, y las importaciones pueden producir entre 100k-1mil + registros. Esto equivale a una carga útil que oscila entre varios MB y unos pocos cientos de MB de datos.

Sé que las tablas temporales son otra opción, pero este método parece muy útil.

¿Hay alguna advertencia a tener en cuenta con respecto a este tipo de práctica con una gran cantidad de manipulación de datos entre confirmaciones? (Fuera de la ráfaga de carga de escritura / indexación típica una vez confirmada)

— hielo delgado
fuente

Personalmente, me gusta tener un equilibrio. Hago importaciones en transacciones de 1k o 10k, porque sé que llegaría a alrededor de 900k filas y luego se bloquearía debido al tamaño del búfer o algo más ridículo. Bastante fácil de aprender de eso, y no tanto de E / S.

— Capitán Hipertexto

Un cuello de botella a tener en cuenta es el InnoDB Log Buffer. Innodb_log_buffer_size establece el tamaño . Esto es lo que dice la documentación de MySQL al respecto:

El tamaño en bytes del búfer que InnoDB usa para escribir en los archivos de registro en el disco. El valor predeterminado es 8 MB. Un búfer de registro grande permite ejecutar grandes transacciones sin necesidad de escribir el registro en el disco antes de que se confirmen las transacciones. Por lo tanto, si tiene grandes transacciones, agrandar el búfer de registro ahorra E / S de disco.

El InnoDB Log Buffer no debe confundirse con el InnoDB Buffer Pool. La principal diferencia entre ellos es su propósito. El InnoDB Log Buffer básicamente registrará los cambios a corto plazo que se escriben en los registros de rehacer (ib_logfile0, ib_logfile1). El InnoDB Buffer Pool (dimensionado por innodb_buffer_pool_size ) almacena en caché los datos y las páginas de índice que deben confirmarse (si las páginas están sucias) y eventualmente escribirse) en el disco. Una vez confirmados, las páginas de cambios permanecen en la RAM hasta que se eliminen mediante las reglas LRU.

Las grandes transacciones deben canalizarse a través del Log Buffer. Como se mencionó, un búfer de registro más grande reducirá la E / S del disco. Solo una gran confirmación presentaría un cuello de botella.

Es posible que desee buscar otras opciones de InnoDB para configurar.

innodb_flush_method : Esto determina cómo se maneja el vaciado y si se permite o no que el sistema operativo guarde en caché las escrituras en InnoDB ( debe experimentar entre O_DSYNC y O_DIRECT )
innodb_read_io_threads (Use el máximo: 64)
innodb_write_io_threads (Use el máximo: 64)
innodb_io_capacity (use valores más altos como 5000 o 10000, pero el hardware lo superará por usted, en otras palabras, deje que el hardware decida la capacidad de E / S una vez que asigne un gran número)
innodb_thread_concurrency : el valor predeterminado es 0. Aprendí de primera mano de Ronald Bradford en Percona NYC 2011 para dejar este número en 0. Le permite a InnoDB decidir la mejor cantidad de tickets de concurrencia que pueda manejar)

Tengo otras publicaciones sobre la optimización de InnoDB para futuras investigaciones.

— RolandoMySQLDBA
fuente

de alguna manera sabía que estarías en esto. Gracias por las respuestas exhaustivas que siempre pareces dar. Pregunta secundaria: ¿Tiene algún recurso sobre el uso de innodb_io_capacity? Cuando la documentación sugiere que un SATA de consumo de 5400 / 7200RPM tiene un valor de 100, ¿es su estrategia que sugiera simplemente 'eliminar el límite' estableciendo ese valor tan alto?

— thinice

Por lo general, configuro innodb_io_capacity más alto y dejo que el hardware lo supere. Agregaré esto a mi respuesta ahora mismo.

— RolandoMySQLDBA