Una de las preguntas más frecuentes al crear una tabla de MySQL es ¿qué elijo, MyISAM o InnoDB? Mucha gente decide de forma un poco aleatoria. Tanto MyISAM como InnoDB son motores de almacenamiento. El motor de almacenamiento es la capa de software que se coloca debajo del motor de consultas (la parte que se encarga de analizar y optimizar las consultas de SQL). Se encarga de hacer todo el trabajo «sucio» de localizar cada byte en el soporte físico, de asegurarse de que se cumplen las restricciones de integridad, de la concurrencia, etc.

Esta es la parte más compleja del sistema gestor de bases de datos, se compone de cientos de miles de líneas de código altamente optimizado. Cada motor de almacenamiento soporta unas características diferentes.

• MyISAM: motor de almacenamiento simplificado. Trabaja con los datos de una forma más «relajada», con el objetivo de simplificar su uso y tratar de mejorar el rendimiento. Normalmente las tablas ocuparán menos espacio en disco. Suelen ser más rápidas para consultas de datos. Su contrapartida es que no sigue las 12 reglas de Codd, no tiene control de claves foráneas, transacciones, su control de la concurrencia es muy limitado, etc..
• InnoDB: motor más sofisticado que cumple con las reglas del modelo relacional bastante a rajatabla. Por ello, garantiza una mayor durabilidad en los datos. En sus inicios se criticaba que añadía muchas características pero era mucho más lento que MyISAM. Esto ya no es un problema y en determinadas circunstancias le supera en rendimiento (sobre todo en modificaciones concurrentes de datos y en consultas indexadas por clave primaria).

Lo más importante es no mezclar tablas de distintos motores de almacenamiento. De lo contrario hacer un JOIN entre dos tablas de distinto tipo el rendimiento será pésimo. MySQL tratará de optimizarlo lo más posible, pero no podrá hacer milagros. Es posible que tenga sentido tener alguna tabla de un tipo distinto en determinadas circunstancias. Por ejemplo, podemos tener los datos vitales en tablas InnoDB y tener tablas con logs/registros en MyISAM porque no requieren de mucha complejidad.

A continuación detallaremos diez razones por las cuales InnoDB puede ser la opción correcta frente a MyISAM:

1.  Soporte de claves foráneas. InnoDB permite relacionar tablas de forma implícita en la base de datos. Esto hará que la propia base de datos se encargue de eliminar inconsistencias en los datos. Con MyISAM tendríamos que «asumir» las claves foráneas, pero podríamos obtener registros inválidos. Por ejemplo, no podemos asegurarnos de que si borramos un producto, primero tengamos que borrar las categorías asociadas al mismo. Con MyISAM podríamos borrar un producto y la tabla de producto_categoria quedaría con registros huérfanos.
2. Control de concurrencia de alto nivel. En MyISAM cuando una transacción modifica un registro de una tabla, la tabla entera queda bloqueada mientras se realice la modificación. Cualquier otra transacción que se realice mientras tanto tendrá que esperar. Eso puede crear cuellos de botella. Es muy común ver listas de procesos con cientos de INSERTs que están esperando a otro que se ha quedado atascado. Ante eso poco más se puede hacer que reiniciar el servidor o matar los procesos. InnoDB en cambio, proporciona un sistema de bloqueos a nivel de fila, lo que significa que solamente la fila que está siendo modificada queda bloqueada. Otras transacciones tratando de modificar la misma tabla podrían funcionar siempre y cuando modifiquen a otros registros. Modificar una tabla de forma concurrente es altamente probable. Modificar un mismo registro simultáneamente es mucho menos común.
3. Bajo índice de tablas corruptas. Esto es debido en parte al punto 2. Debido al mal control de concurrencia de MyISAM, es muy habitual encontrarse con tablas corruptas si una transacción falla. En InnoDB se cumple la norma de que cualquier transacción llevará a la base de datos de un estado válido a otro estado válido. Muy raramente encontraremos una tabla InnoDB corrupta. Aunque cabe mencionar que reparar una tabla MyISAM es trivial mientras que en InnoDB puede llegar a ser una pesadilla.
4. Soporte de transacciones. InnoDB soporta las transacciones. Es posible enviar una serie de consultas que se ejecuten de forma unificada. Así podemos crear aplicaciones con alto índice de fiabilidad, porque podemos asegurarnos de que no dejamos una operación a medio hacer. Cabe destacar que por defecto, el parámetro «autocommit» está activado, así que si queremos utilizarlas tendremos que o bien especificarlo (ver cómo) o desactivar esa opción.
5. Índices clusterizados. Los datos se almacenan físicamente por orden (alfabético o numérico según se aplique) del valor de la clave primaria. Consultas que filtren únicamente por la clave primaria serán extremadamente eficientes, porque con saber el valor que buscamos, InnoDB con un par de operaciones ya puede saber dónde se encuentra el dato.
6. Mejores opciones de replicación. La replicación consiste en copiar los datos de MySQL en varios servidores para repartir el trabajo a la hora de realizar consultas de datos. Al usar la replicación es fundamental que todos los nodos (servidores con copia de la base de datos) tengan una copia consistente de los datos, de lo contrario cada nodo podría devolver resultados distintos. Esto sólo lo puede garantizar InnoDB mediante sus transacciones y su avanzado sistema de bloqueos.
7. Más escalabilidad. Las tablas MyISAM frecuentemente quedan bloqueadas y/o corruptas. En una tabla que almacene 200 registros esto puede ser un problema menor, porque repararla llevaría dos segundos. En una tabla con 20 millones de registros y que ocupe 2GB de espacio en disco esto es inaceptable. Podríamos dejar la aplicación inutilizada durante horas. Si predecimos que nuestra tabla crecerá mucho en tamaño o en requisitos de acceso, deberíamos considerar a InnoDB como opción.
8. Motor ACID compliant. Estas son las siglas de Atomicidad, Consistencia, Aislamiento y Durabilidad. La base de datos siempre va de un estado válido a otro estado válido.
9. Tablas sin límite de tamaño. En MyISAM cada tabla se guarda en un archivo por separado. Si la tabla supera los 2GB es posible que el sistema de archivos del sistema operativo no sea capaz de utilizarlo. InnoDB se encarga de que las tablas no tengan límite de tamaño. Para ello es posible que necesite dividir los datos en ficheros más pequeños. MyISAM no cuenta con esas características y tiene que depender 100% del sistema de archivos.
10. Índices hash adaptables. Si un índice cabe en la memoria RAM y una tabla es consultada frecuentemente, es posible que InnoDB cree automáticamente un índice hash en memoria. Lo que hace es replicar el índice que se guarda en disco en la memoria RAM, de tal manera que los accesos tengan una velocidad muy superior. Es un sistema muy complejo que puede aumentar el rendimiento de las consultas significativamente.