Con el lanzamiento de la rama de MySQL 5.5.x, InnoDB se ha convertido en el motor de almacenamiento por defecto, ya que antes era MyISAM.

Todos los que antes de comenzar a utilizar MySQL 5.5 se inició con MyISAM. Fue el motor de almacenamiento por defecto y tenías que buscarte la vida para utilizar otro motor. Fue una buena base de datos buscando, robusto, simple y rápido en muchos aspectos.

Pero llegó con las transacciones de InnoDB, bloqueo a nivel de fila, y una mejor recuperación de una caída de MyISAM. En algunos casos el rendimiento de algunos puntos de referencia InnoDB estaba detrás de MyISAM (selects, MyISAM leía más rápido que InnoDB).  Estaba, ya no lo está.

Ahora el rendimiento para la mayoría de las aplicaciones es mucho mejor con InnoDB a MyISAM. Y por eso a partir MySQL 5.5, InnoDB es el motor de almacenamiento por defecto.

Pero y si yo no necesito transacciones, no necesito el bloqueo de fila, y no me preocupa que la tabla se pueda corromper. ¿Entonces no necesito InnodB? También, porque la mayoría de las nuevas características están diseñadas alrededor de InnoDB. La agrupación de subprocesos, por ejemplo, va a aumentar en gran medida de la transacción por segundo y las transacciones son territorio InnoDB. La compresión de datos InnoDB permite leer más rápido en el disco duro.

Hay una gran cantidad de mitos que rodean el motor InnoDB ("más lento en Lecturas ',' sólo se utiliza si necesita claves foráneas o transacciones"). Básicamente, en MySQL 5.0, InnoDB todavía tenía problemas, en 5.5 no.

Pero InnoDB necesita optimización y tuning. InnoDB necesita afinación. En serio. MyISAM para muchas aplicaciones se puede trabajar bien con los valores por defecto. Se han visto a cientos de bases de datos con GB funcionando con MyISAM con la configuración predeterminada y ha funcionado razonablemente. InnoDB necesita recursos y no va a funcionar bien con los valores predeterminados.

Aún habiendo dicho todo lo anterior, si tenemos un foro, wiki, blog, cms o lo que sea, con gran porcentaje de consutlas sql de lecutra ( select (80% o más que suele ser lo habitual) se recomienda usar el motor MyISAM, porque es mucho más rápido y consume mucha menos cpu.

Aunque como siempre, cada caso es personalizado y lo mejor es realizar un test, benchmark para elegir adecuadamente el motor que mejor se ajuste a nuestras necesidades (ya sea de hardware o de tipos de consulta).

Motor de almacenamiento MyISAM (storage-engine)

El tipo MyISAM era el motor de almacenamiento por defecto que se le asigna a las tablas que se crean, si no se le indica que utilice otro tipo de motor. Se basa en el código ISAM lo que hace que sean tablas muy fiables, pero añadiendo nuevas características.

Cada tabla MyISAM se almacena en disco en tres ficheros. Los ficheros tienen nombres que comienzan con el nombre de tabla y tienen una extensión para indicar el tipo de fichero. Un fichero .FRM almacena la definición de tabla. El fichero de datos tiene una extensión .MYD mientras que el fichero índice tiene una extensión .MYI.

Uso de recursos: MyISAM consume una menor cantidad de memoria con respecto a su principal competidor, InnoDB, lo que la convierte en la mejor opción cuando se trata de servidores con recursos limitados.


MyISAM vs InnoDB - Diferencias Ventajas Desventajas Inconvenientes

MyISAM

- Bloqueo de tabla
- Aumento del rendimiento si nuestra aplicación realiza un elevado número de consultas “Select”.
- Las tablas pueden llegar a dar problemas en la recuperación de datos.
- Permite hacer búsquedas full-text (se puede arreglar con Sphinx)
- Menor consumo memoria RAM

    Mayor velocidad en general a la hora de recuperar datos.
    Recomendable para aplicaciones en las que dominan las sentencias SELECT ante los INSERT / UPDATE.
    Ausencia de características de atomicidad ya que no tiene que hacer comprobaciones de la integridad referencial, ni bloquear las tablas para realizar las operaciones, esto nos lleva como los anteriores puntos a una mayor velocidad.

InnoDB

- Bloqueo de registros
- Soporte de transacciones
- Rendimiento
- Concurrencia
- Confiabilidad

 Nos permite tener las características ACID (Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español), garantizando la integridad de nuestras tablas.

Integridad de datos, cuando los contenidos se modifican con sentencias INSERT, DELETE o UPDATE, la integridad de los datos almacenados puede perderse de muchas maneras diferentes.

InnoDB se recupera de errores o reinicios no esperados del sistema a partir de sus logs, mientras que MyISAM requiere una exploración, reparación y reconstrucción de índices de los datos de las tablas que aún no habían sido volcadas a disco.

Además es probable que si nuestra aplicación hace un uso elevado de INSERT y UPDATE notemos un aumento de rendimiento con respecto a MyISAM.

Explicación Bloqueo de tablas:

Por ejemplo, cada vez que vea un tema en SMF, esto ocurre:

UPDATE smf_topics
SET numViews numViews = + 1
DONDE = ID_TOPIC # # #
LIMIT 1;

Si la tabla está bloqueada, tendrá que esperar a que ... lo que esté sucediendo hasta el final. Lo mismo ocurre con varias personas viendo varios temas a la vez. Tienen que esperar en fila para la tabla de temas que estén disponibles.

Esto no es cierto para InnoDB. Si dos personas ver el mismo tema, sí ... tendrán que esperar a la actualización numViews. Pero si ellos ven diferentes temas, es inmediata.