innodb_additional_mem_pool_size

El tamaño del pool de memoria que InnoDB utiliza para almacenar información del diccionario de datos y otras estructuras de datos internas. Mientras más tablas se tengan en la aplicación, mayor será este tamaño. Si InnoDB se queda sin memoria en este pool, comenzará a tomar memoria del sistema operativo, y dejará mensajes de advertencia en el log de errores de MySQL. El valor por defecto es 1MB.

innodb_autoextend_increment

El tamaño a incrementar (en megabytes) cuando se extiende el tamaño de un espacio de tablas autoextensible, luego de llenarse. El valor por defecto es 8. Esta opción puede cambiarse en tiempo de ejecución como una variable de sistema global.

innodb_buffer_pool_awe_mem_mb

El tamaño (en MB) del pool de buffer, si está ubicado en la memoria AWE en Windows de 32 bits, y sólo relevante en este tipo de sistemas operativos. Si el sistema operativo Windows de 32 bits en uso soporta más de 4GB de memoria, usualmente llamado “Address Windowing Extensions”, se puede ubicar el pool del buffer de InnoDB dentro de la memoria física AWE utilizando este parámetro. El máximo valor posible es de 64000. Si se especifica este parámetro, innodb_buffer_pool_size es la ventana en el espacio de direcciones de 32 bits de mysqld donde InnoDB direcciona la memoria AWE. Un valor adecuado para innodb_buffer_pool_size son 500MB.

innodb_buffer_pool_size

El tamaño del buffer de memoria que InnoDB emplea para el almacenamiento intermedio de los datos e índices de sus tablas. Mientras más grande sea este valor, menores operaciones de E/S en disco serán necesarias para acceder a los datos de las tablas. En un servidor de bases de datos dedicado, se puede establecer este valor en hasta el 80% de la memoria física del ordenador. Sin embargo, no debe establecerse en un valor demasiado grande porque la pugna por la memoria física podría causar que el sistema operativo comience a paginar.

innodb_checksums

InnoDB emplea validación por sumas de verificación (checksums) en todas las páginas leídas desde el disco, para asegurar una tolerancia extra contra fallas frente a hardware averiado o ficheros corruptos. Sin embargo, bajo ciertas circunstancias inusuales (por ejemplo al ejecutar pruebas de rendimiento) esta característica extra de seguridad es innecesaria. En tales casos, esta opción (que está habilitada por defecto) puede deshabilitarse con --skip-innodb-checksums. Esta opción fue agregada en MySQL 5.0.3.

innodb_data_file_path

Las rutas a los ficheros individuales de datos y sus tamaños. La ruta de directorio completa a cada fichero de datos se obtiene concatenando innodb_data_home_dir con cada ruta especificada aquí. Los tamaños de fichero se especifican en megabytes o gigabytes (1024MB) agregando M o G al valor que representa el tamaño. La sumatoria de los tamaños de fichero debe ser de al menos 10MB. En algunos sistemas operativos, los ficheros deben tener menos de 2GB. Si no se indica innodb_data_file_path, el comportamiento predeterminado de inicio es crear un único fichero autoextensible de 10MB llamado ibdata1. En aquellos sistemas operativos que soporten ficheros grandes, se puede establecer el tamaño de fichero en más de 4GB. También pueden utilizarse como ficheros de datos particiones de dispositivos en bruto. Consulte Sección 15.14.2, “Usar dispositivos en bruto (raw devices) para espacios de tablas”.

innodb_data_home_dir

La porción común de la ruta de directorio para todos los ficheros de datos InnoDB. Si este valor no se establece, por defecto será el directorio de datos de MySQL. También puede especificarse como una cadena vacía, en cuyo caso se podrán utilizar rutas absolutas en innodb_data_file_path.

innodb_doublewrite

Por defecto, InnoDB almacena todos los datos dos veces, la primera en el buffer de escritura doble (o doublewrite), y luego a los ficheros de datos reales. Esta opción puede emplearse para desactivar dicha funcionalidad. Al igual que innodb_checksums, esta opción está habilitada por defecto; puede desactivarse con --skip-innodb-doublewrite en pruebas de rendimiento o casos en que el máximo desempeño prevalezca sobre la preocupacion por la integridad de los datos o las posibles fallas. Esta opción se agregó en MySQL 5.0.3.

innodb_fast_shutdown

Si se establece a 0, InnoDB efectúa una descarga completa y vuelca los buffers de inserción antes de llevar a cabo el cierre del servidor. Estas operaciones pueden tomar minutos o incluso horas en casos extremos. Si se establece en 1, InnoDB pasa por alto estas operaciones al cierre. El valor por defecto es 1. Si se establece en 2 (opción que está disponible desde MySQL 5.0.5, excepto en Netware), InnoDB simplemente vuelca a disco sus registros (logs) y se cierra en frío, como si hubiera ocurrido una caída; ninguna transacción confirmada se perderá, pero en el siguiente inicio se ejecutará una recuperación ante caídas.

innodb_file_io_threads

El número de subprocesos (threads) de E/S de fichero en InnoDB. Normalmente esto debería ser dejado en el valor predeterminado de 4, pero la E/S de disco en Windows puede beneficiarse con un número mayor. En Unix, incrementar el número no tiene efecto; InnoDB siempre utiliza el valor predeterminado.

innodb_file_per_table

Esta opción provoca que InnoDB cree cada nueva tabla utilizando su propio fichero .ibd para almacenar datos e índices, en lugar de colocarlo en el espacio de tablas compartidas. Consulte Sección 15.6.6, “Usar un espacio de tablas para cada tabla”.

innodb_flush_log_at_trx_commit

Cuando innodb_flush_log_at_trx_commit se establece en 0, una vez por segundo el buffer de registros (log buffer) se graba en el fichero de registro y se vuelca a disco, pero no se hace nada al confirmar una transacción. Cuando este valor es 1 (predeterminado), cada vez que se confirma una transacción el buffer de registros (log buffer) se graba en el fichero de registro y se vuelca a disco Cuando se establece en 2, el buffer de registros (log buffer) se graba en el fichero de registro, pero no se vuelca a disco. Sin embargo, el volcado a disco del fichero de registro se produce una vez por segundo también cuando vale 2. Se debe tener en cuenta que el volcado una vez por segundo no está 100% garantizado que ocurra en cada segundo, debido a cuestiones de programación (scheduling) de procesos. Se puede alcanzar un mayor rendimiento estableciendo un valor diferente de 1, pero en caso de caída se puede perder un segundo de transacciones. Si se establece el valor en 0, cualquier caída en un proceso de mysqld puede borrar el último segundo de transacciones. Si se establece el valor en 2, entonces únicamente una caída del sistema operativo o una interrupción de energía pueden borrar el último segundo de transacciones. Hay que notar que muchos sistemas operativos y algunos tipos de discos puedne ser engañosos en las operaciones de volcado a disco. Podrían indicarle a mysqld que el volcado ha tenido lugar, aunque no sea así. En tal caso la estabilidad de las transacciones no está garantizada ni aún con el valor 1, y en el peor de los casos una interrupción de energía puede incluso corromper la base de datos InnoDB. Utilizar un caché de disco apoyado por baterías en el controlador de disco SCSI o en el propio disco, acelera los volcados a disco, y hace más segura la operación. También puede intentarse con el comando de Unix hdparm, el cual deshabilita el almacenamiento en caches de hardware de las operaciones de escritura a disco, o utilizar algún otro comando específico del fabricante del hardware. El valor por defecto de esta opción es 1

innodb_flush_method

Esta opción solamente es relevante en sistemas Unix. Si se establece en fdatasync (el valor predeterminado), InnoDB utiliza fsync() para volcar tanto los ficheros de datos como de registro (log). Si se establece en O_DSYNC, InnoDB emplea O_SYNC para abrir y volcar los ficheros de registro, pero utiliza fsync() para volcar los ficheros de datos. Si se especifica O_DIRECT (disponible en algunas versiones de GNU/Linux), InnoDB utiliza O_DIRECT para abrir los ficheros de datos, y fsync() para volcar tanto los ficheros de datos como de registro. Nótese que InnoDB emplea fsync() en lugar de fdatasync(), y no emplea O_DSYNC por defecto porque han ocurrido problemas con éste en muchas variedades de Unix.

innodb_force_recovery

Advertencia: Esta opción debería ser definida solamente en una situación de emergencia cuando se desean volcar las tablas desde una base de datos corrupta. Los posibles valores van de 1 a 6. Los significados de estos valores se describen en Sección 15.8.1, “Forzar una recuperación”. Como una medida de seguridad, InnoDB impide que un usuario modifique datos cuando esta opción tiene un valor mayor a 0.

innodb_lock_wait_timeout

El límite de tiempo, en segundos, que una transacción InnoDB puede esperar por un bloqueo antes de ser cancelada. InnoDB automáticamente detecta bloqueos mutuos (deadlocks) en su propia tabla de bloqueos, y cancela la transacción. InnoDB detecta los bloqueos por el uso de la sentencia LOCK TABLES. El valor predeterminado es de 50 segundos.

Para conseguir la mayor estabilidad y consistencia posibles en una configuración de replicación, se debería utilizar innodb_flush_logs_at_trx_commit=1, sync-binlog=1, y innodb_safe_binlog en el fichero my.cnf principal.

innodb_locks_unsafe_for_binlog

Esta opción desactiva el bloqueo de la clave siguiente en búsquedas y exploraciones de índices InnoDB. El valor por defecto de esta opción es falso.

Normalmente, InnoDB utiliza un algoritmo denominado bloqueo de clave siguiente (next-key). InnoDB efectúa un bloqueo a nivel de fila de tal forma que cuando busca o explora el índice de una tabla, establece bloqueos compartidos o exclusivos en cualquier registro de índice que encuentre. El bloqueo que InnoDB establece en registros de índice también afecta al “vacío” que precede a ese registro. Si un usuario tiene un bloqueo compartido o exclusivo sobre el registro R en un índice, otro usuario no puede insertar un nuevo registro de índice inmediatamente antes de R en el orden del índice. Esta opción provoca que InnoDB no utilice el bloqueo de clave siguiente en búsquedas o exploraciones de índices. El bloqueo de clave siguiente es todavía utilizado para asegurar las restricciones de claves foráneas y la verificación de claves duplicadas. Nótese que el uso de esta opción puede provocar problemas secundarios: suponiendo que se deseen leer y bloquear todos los registros hijos de la tabla child que tengan un identificador mayor a 100, junto al posterior intento de actualizar algunas columnas en las filas seleccionadas:

SELECT * FROM child WHERE id > 100 FOR UPDATE;

Supóngase que hay un índice sobre la columna id. La consulta explora aquel índice comenzando por el primer registro en que id sea mayor que 100. Si el bloqueo efectuado sobre los registros del índice no bloquea las inserciones realizadas en los espacios vacíos, en la tabla se insertará un nuevo registro. Si se ejecuta el mismo SELECT dentro de la misma transacción, se verá un nuevo registro en el conjunto de resultados devuelto por la consulta. Esto también significa que si se agregan nuevos elementos a la base de datos, InnoDB no garantiza la serialización; sin embargo, los conflictos de serialización aún están garantizados. Por lo tanto, si esta opción se utiliza, InnoDB garantiza como mucho el nivel de aislamiento READ COMMITTED.

A partir de MySQL 5.0.2 esta opción es aún más insegura. InnoDB en un UPDATE o DELETE solamente bloquea los registros que se actualizan o borran. Esto reduce notablemente la probabilidad de bloqueos mutuos (deadlocks), pero aún pueden ocurrir. Nótese que esta opción todavía no le permite a operaciones como UPDATE predominar sobre otras operaciones similares (como otro UPDATE) aún en el caso en que actúen sobre registros diferentes. Considérese lo siguiente: example:

CREATE TABLE A(A INT NOT NULL, B INT);
INSERT INTO A VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT;

Si una conexión realiza una consulta:

SET AUTOCOMMIT = 0;
UPDATE A SET B = 5 WHERE B = 3;

y la otra conexión ejecuta otra consulta a continuación de la primera:

SET AUTOCOMMIT = 0;
UPDATE A SET B = 4 WHERE B = 2;

La consulta dos tendrá que esperar la confirmación o la cancelación de la consulta uno, porque ésta tiene un bloqueo exclusivo en el registro (2,3), y la consulta dos, mientras explora los registros, también intenta colocar un bloqueo exclusivo en la misma fila, cosa que no puede hacer. Esto se debe a que la consulta dos primero establece el bloqueo sobre un registro y luego determina si el registro pertenece al conjunto de resultados, y si no es así libera el bloqueo innecesario, cuando se emplea la opción innodb_locks_unsafe_for_binlog.

Por lo tanto, la consulta uno se ejecuta de este modo:

x-lock(1,2)
unlock(1,2)
x-lock(2,3)
update(2,3) to (2,5)
x-lock(3,2)
unlock(3,2)
x-lock(4,3)
update(4,3) to (4,5)
x-lock(5,2)
unlock(5,2)

entonces la consulta dos se ejecuta así:

x-lock(1,2)
update(1,2) to (1,4)
x-lock(2,3) - wait for query one to commit or rollback

innodb_log_arch_dir

El directorio donde los ficheros de registro (logs) terminados se archivarán si se utiliza el archivo de ficheros de registro. Si se utiliza, el valor de este parámetro debería ser el mismo que innodb_log_group_home_dir. Sin embargo, no es requerido.

innodb_log_archive

Este valor generalmente debería establecerse a 0. Debido a que la recuperación a partir de una copia de respaldo es realizada por MySQL empleando sus propios ficheros de registro (log), en general no hay necesidad de archivar los ficheros de registro de InnoDB. El valor predeterminado para esta opción es 0.

innodb_log_buffer_size

El tamaño del buffer que InnoDB emplea para escribir los ficheros de registro (logs) en disco. Los valores razonables se encuentran entre 1MB y 8MB. El valor predeterminado es 1MB. Un buffer de fichero de registro grande le permite a las transacciones extensas ejecutarse sin necesidad de guardar el fichero de registro en disco antes de que la transacción se confirme. Por lo tanto, si se manejan grandes transacciones, incrementar el tamaño del buffer de ficheros de registro ahorra operaciones de E/S en disco.

innodb_log_file_size

El tamaño de cada fichero de registro (log) en un grupo de ficheros de registro. El tamaño combinado de estos ficheros debe ser inferior a 4GB en ordenadores de 32 bits. El valor predeterminado es de 5MB. El rango de valores razonables va desde 1MB hasta la 1/N parte del tamaño del pool de buffer, donde N es la cantidad de ficheros de registro en el grupo. Mientras mayor es el valor, menor es la cantidad de guardado de puntos de verificación que se necesitan en el pool de buffer, ahorrando operaciones de E/S en disco. Pero tener ficheros de registro más grandes también significa que la recuperación es más lenta en caso de caídas.

innodb_log_files_in_group

En un grupo de ficheros de registro (logs), es la cantidad de ficheros que contiene. InnoDB escribe en los ficheros siguiendo una forma circular. El valor predeterminado es 2 (recomendado).

innodb_log_group_home_dir

La ruta de directorio a los ficheros de registro (log) de InnoDB. Debe tener el mismo valor que innodb_log_arch_dir. Si no se especifican parámetros de ficheros de registro InnoDB, la acción predeterminada es crear dos ficheros de 5MB llamados ib_logfile0 y ib_logfile1 en el directorio de datos de MySQL.

innodb_max_dirty_pages_pct

Un entero en el rango de 0 a 100. El valor por defecto es 90. El subproceso (thread) principal en InnoDB intenta volcar páginas desde el pool de buffer de modo que a lo sumo este porcentaje de las páginas aún sin volcar sea volcado en un momento determinado. Si se tiene el privilegio SUPER, este porcentaje pude cambiarse mientras el servidor está en ejecución:

SET GLOBAL innodb_max_dirty_pages_pct = value;

innodb_max_purge_lag

Esta opción controla la forma de retrasar las operaciones INSERT, UPDATE y DELETE cuando las operaciones de descarga (ver Sección 15.12, “Implementación de multiversión”) están sufiendo demoras. TEl valor por defecto de este parámetro es cero, lo que significa que no se retrasarán. Esta opción puede modificarse en tiempo de ejecución como una variable global de sistema.

El sistema de transacciones de InnoDB mantiene una lista de transacciones que tienen entradas en los índices marcadas para ser eliminadas por operaciones UPDATE o DELETE. Se deja que la longitud de esta lista sea purge_lag. Cuando purge_lag excede a innodb_max_purge_lag, cada operación de INSERT, UPDATE y DELETE se retrasa durante ((purge_lag/innodb_max_purge_lag)*10)-5 milisegundos. El retraso se computa en el comienzo de un lote de depuración, cada diez segundos. Las operaciones no se retrasan si no puede ejecutarse la depuración debido a una vista de lectura consistente (consistent read) anterior que contenga los registros a ser depurados.

Un escenario típico para una carga de trabajo problemática podría ser 1 millón, asumiendo que las transacciones son pequeñas, sólo 100 bytes de tamaño, y se pueden permitir 100 MB de registros sin descargar en las tablas.

innodb_mirrored_log_groups

El número de copias idénticas de grupos de ficheros de registro que se mantienen para la base de datos. Actualmente debería establecerse en 1.

innodb_open_files

Esta opción sólo es relevante si se emplean múltiples espacios de tablas en InnoDB. Especifica el número máximo de ficheros .ibd que InnoDB puede mantener abiertos al mismo tiempo. El mínimo es 10. El valor predeterminado es 300.

Los descriptores de fichero empleados para ficheros .ibd son únicamente para InnoDB. Son independientes de los especificados por la opción de servidor --open-files-limit, y no afectan la operación del caché de tablas.

innodb_safe_binlog

Contribuye a asegurar la consistencia entre el contenido de las tablas InnoDB y el registro binario (binary log). Consulte Sección 5.10.3, “El registro binario (Binary Log)”.

innodb_status_file

Esta opción provoca que InnoDB cree un fichero <datadir>/innodb_status.<pid> para la salida períodica de SHOW INNODB STATUS. Disponible desde MySQL 4.0.21.

innodb_table_locks

InnoDB respeta lo establecido por LOCK TABLES, y MySQL no retorna desde un LOCK TABLE .. WRITE hasta que todos los otros flujos (threads) han levantado sus bloqueos a la tabla. El valor por defecto es 1, lo cual significa que LOCK TABLES causará que InnoDB bloquee una tabla internamente. En aplicaciones que emplean AUTOCOMMIT=1, los bloqueos internos de tabla de InnoDB pueden originar bloqueos mutuos (deadlocks). Se puede establecer innodb_table_locks=0 en my.cnf (o my.ini en Windows) para eliminar ese problema.

innodb_thread_concurrency

InnoDB intenta mantener el número de flujos (threads) del sistema operativo que concurren dentro de InnoDB en un valor menor o igual al límite especificado por este parámetro. Antes de MySQL 5.0.8, el valor por defecto es 8. Si se tienen dificultades de rendimiento, y SHOW INNODB STATUS indica que hay muchos subprocesos esperando por semáforos, se podrían tener subprocesos pugnando por recursos, y se debería establecer este parámetro en un número mayor o menor. Si se posee un ordenador con varios procesadores y discos, se puede intentar aumentar el valor para hacer mejor uso de los recursos del ordenador. Un valor recomendado es la suma del número de procesadores y discos que tiene el sistema. Un valor de 500 o mayor deshabilitará la verificación de concurrencia. A partir de MySQL 5.0.8, el valor por defecto es 20, y la verificación de concurrencia se deshabilita si se establece en 20 o más.

innodb_status_file

Esta opción provoca que InnoDB cree un fichero <datadir>/innodb_status.<pid> para almacenar periódicamente la salida de SHOW INNODB STATUS.