Si la utilidad top de Unix o el Administrador de Tareas de Windows muestra que el porcentaje de uso de CPU durante la carga de trabajo es inferior al 70%, probablemente se está trabajando directamente sobre el disco. Podría suceder que se estén produciendo excesivas confirmaciones de transacciones, o que el pool de buffer sea muy pequeño. Puede ser de ayuda incrementar el tamaño del buffer, pero no debe alcanzar ni superar el 80% del total de la memoria física del ordenador.

Incluir varias modificaciones en una sola transacción. InnoDB debe descargar su registro (log) al disco cada vez que se confirma una transacción, si dicha transacción realiza modificaciones en la base de datos. Dado que la velocidad de rotación de un disco es generalmente de 167 revoluciones por segundo, esto restringe el número de confirmaciones a la misma fracción de segundo si el disco no “engaña” al sistema operativo.

Si es aceptable la pérdida de alguna de las últimas transacciones confirmadas, se puede establecer en my.cnf el parámetro innodb_flush_log_at_trx_commit a un valor de 0. InnoDB intenta descargar el registro (log) una vez por segundo en cualquier caso, aunque la descarga no está garantizada.

Incrementar el tamaño de los ficheros de registro (log), incluso hasta equiparar el tamaño del pool de buffer. Cuando InnoDB ha colmado la capacidad de los ficheros de log, debe escribir los contenidos modificados desde el pool de buffer al disco en un punto de verificación. Los ficheros de log pequeños pueden causar escrituras en disco innecesarias. La desventaja de los ficheros de log grandes es que la recuperación demanda más tiempo.

También el buffer del log debe ser suficientemente grande (en el orden de los 8MB).

Emplear el tipo de columna VARCHAR en lugar de CHAR si se almacenarán cadenas de longitud variable o si la columna contendrá muchos valores NULL. Una columna CHAR(N) siempre utiliza N bytes para almacenar los datos, inclusive si la cadena es más corta o es NULL. Las tablas más pequeñas aprovechan mejor el espacio del pool de buffer y reducen las operaciones de E/S en disco.

Cuando se utiliza row_format=compact (el formato de registro predeterminado para InnoDB en MySQL 5.0) y un conjunto de caracteres de longitud variable como utf8 o sjis, CHAR(N) ocupará una cantidad variable de espacio, con un mínimo de N bytes.

En algunas versiones de GNU/Linux y Unix, descargar ficheros a disco con la función de Unix fsync() (la cual es utilizada en forma predeterminada por InnoDB) y otros métodos similares, es sorprendentemente lento. Si no se está satisfecho con el rendimiento de las operaciones de escritura de la base de datos, se puede intentar establecer el valor de innodb_flush_method en my.cnf a O_DSYNC, si bien O_DSYNC parece ser más lento en otros sistemas.

Durante el empleo del motor de almacenamiento InnoDB en arquitecturas Solaris 10 para x86_64 (AMD Opteron), es importante usar la opción forcedirectio al montar cualquier sistema de ficheros usado para almacenar los ficheros relacionados con InnoDB (el comportamiento predeterminado en Solaris 10/x86_64 es no utilizar esta opción al montar el sistema de ficheros). Si no se utiliza forcedirectio se producirá una seria degradación en la velocidad y rendimiento de InnoDB en esta plataforma.

Al importar datos dentro de InnoDB, hay que asegurarse de que MySQL no tiene habilitado el modo de ejecución automática (autocommit) porque provocaría una descarga del log a disco en cada inserción. Para desactivar la ejecución automática durante la operación de importación, hay que encerrarla entre sentencias SET AUTOCOMMIT y COMMIT:

SET AUTOCOMMIT=0;
/* Sentencias de importación SQL ... */
COMMIT;

Si se utiliza la opción --opt con mysqldump, se obtienen ficheros de voclado que son rápidos de importar en una tabla InnoDB, incluso sin encerrarlos en las sentencias SET AUTOCOMMIT y COMMIT.

Tener cuidado con las cancelaciones de inserciones masivas: InnoDB emplea el buffer de inserciones para reducir la cantidad de operaciones de E/S en disco durante las inserciones, pero ese mecanismo no tiene efecto en la cancelación. Una cancelación efectuada directamente sobre el disco puede tomar 30 veces el tiempo que insumen las correspondientes inserciones. Matar el proceso del servidor de bases de datos no es de ayuda, porque la cancelación recomienza al volver a iniciar el servidor. La única forma de librarse de una cancelación fuera de control es incrementar el tamaño del pool de buffer para que la cancelación se haga sobre la CPU y se ejecute más rápidamente, o utilizar un procedimiento especial. Consulte Sección 15.8.1, “Forzar una recuperación”.

También hay que tener cuidado con las operaciones de gran tamaño realizadas directamente sobre el disco. Hay que emplear DROP TABLE y CREATE TABLE para obtener una tabla vacía, no DELETE FROM tbl_name.

Emplear la sintaxis de múltiples filas de INSERT para reducir la carga extra de la comunicación entre el cliente y el servidor si se necesita insertar muchos registros:

INSERT INTO yourtable VALUES (1,2), (5,5), ...;

Esta sugerencia es válida para las inserciones en cualquier tipo de tabla, no solamente en InnoDB.

Si se tienen restricciones UNIQUE en claves secundarias, se puede acelerar la importación desactivando temporalmente, durante la importación, la verificación de tales restricciones:

SET UNIQUE_CHECKS=0;

En tablas grandes, esto ahorra una gran cantidad de operaciones de E/S en disco debido a que InnoDB puede emplear su buffer de inserción para escribir de una vez los registros de indice secundarios.

Si se tienen restricciones FOREIGN KEY en las tablas, se puede acelerar la importación desactivando la verificación de claves foráneas durante la misma:

SET FOREIGN_KEY_CHECKS=0;

Para tablas grandes, esto puede ahorrar gran cantidad de operaciones sobre el disco.

Si a menudo se realizan consultas sobre tablas que no se actualizan con frecuencia, utilizar el cache de consultas:

[mysqld]
query_cache_type = ON
query_cache_size = 10M