Estoy listo para pasar de MyISAM a InnoDB, pero ¿quería saber si había una lista completa de cosas que buscar? Por ejemplo, no he visto ninguna lista que mencione que ejecutar DISABLE KEYSen una tabla InnoDB arrojará una advertencia, excepto la página del manual ALTER TABLE. Es ese tipo de cosas que necesito saber antes de convertir. Pensé que estaría bien con mis consultas, pero aparentemente no.

Aquí hay algunas trampas

Uso de memoria

MyISAM

• solo almacena en caché las páginas de índice.
• keycache compartido (dimensionado por key_buffer_size).
• También puede configurar un keycache dedicado, una o más tablas por tabla de caché .

InnoDB

• almacena en caché las páginas de datos y las páginas de índice.
• un grupo de búferes y un tamaño antes de MySQL 5.5
• 1 o más agrupaciones de almacenamiento intermedio que comienzan con MySQL 5.5

Aquí hay algunas consultas que escribí y publiqué anteriormente sobre cómo elegir un tamaño adecuado para MyISAM Key Cache y InnoDB Buffer Pool .

Índices FULLTEXT

MyISAM

• Admite índices FULLTEXT

InnoDB

• Comenzando con MySQL 5.6, sí, pero aún en versión beta (ACTUALIZACIÓN: MySQL 5.6 existe y tiene índices FULLTEXT. Si está usando la indexación FULLTEXT en MySQL 5.6, asegúrese de estar usando las opciones FULLTEXT específicas de InnoDB )
• Antes de MySQL 5.6, esto significa que no puede convertir MyISAM a InnoDB.

MySQL 5.5 y viceversa

Para localizar qué tablas MyISAM tienen un índice FULLTEXT, ejecute esta consulta:

select tbl.table_schema,tbl.table_name from
(
    select table_schema,table_name
    from information_schema.tables
    where engine='MyISAM'
    and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
    select table_schema,table_name
    from information_schema.statistics
    where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);

Lo que salga de esta consulta no se puede convertir a InnoDB hasta que actualice a MySQL 5.6.

OPTIMIZAR TABLA

MyISAM

• La tabla MyISAM está reducida
• ANALYZE TABLE ejecuta estadísticas de índice en todos los índices

InnoDB

• ANALYZE TABLE es totalmente inútil porque las estadísticas de índice siempre se recopilan
• Con innodb_file_per_table deshabilitado, ibdata1 crecerá
• Con innodb_file_per_table habilitado, el archivo tablespace (.ibd) se reduce

Creo que el mayor problema sería que innodb es transaccional. Querrá saber si las bibliotecas MySQL que utilizan sus aplicaciones auto_commit por defecto o no.

Python , por ejemplo, no se confirma automáticamente. Esto significa que si una aplicación estaba insertando una fila justo antes de cerrar su conexión, esa inserción ahora se revertiría después de modificar a innodb. El script de Python, por ejemplo, debería asegurarse de llamar a connection.commit ();

Otro punto de diferencia podría estar alrededor de las inserciones o actualizaciones de varias filas. Considere una sola inserción de varias filas

insert into tbl values (...row1...),  (...row2...),  (...rowN....);

Tenga en cuenta lo que sucede si hay algún tipo de error, como una colisión de clave única en la fila 3. Con MyISAM, las dos primeras filas se habrían escrito, bajo innodb todas las filas que se están escribiendo se revertirán sin dejar nada escrito ni siquiera en el caso de tal error.

Con innodb entrarás en el mundo de los callejones sin salida. Estos no son inherentemente malos a menos que ocurran con tanta frecuencia para evitar que se realice cualquier trabajo. Sin embargo, sus aplicaciones deberán codificarse de tal manera que anticipen los interbloqueos y los manejen adecuadamente (lo que probablemente significa simplemente volver a intentarlo).

Considere las limitaciones de memoria / almacenamiento. Innodb requiere muchos más recursos que MyISAM. Si tiene suficiente RAM para mantener sus agrupaciones de almacenamiento intermedio lo suficientemente grandes como para acomodar todas sus tablas, entonces está dorado.

Busque tablas que tengan claves principales grandes. La indexación en clúster de Innodb significa que cada índice secundario contiene otra copia de la PK de la fila correspondiente. Si tiene 2 índices secundarios, eso significa que cada fila PK se almacena 3 veces (PK + cada índice). Si el pk se extiende a través de varias columnas y tipos de datos grandes (char (N), por ejemplo), puede ver cómo los requisitos de índice pueden explotar rápidamente en innodb.