Je suis prêt à passer de MyISAM à InnoDB mais je voulais savoir s'il y avait une liste complète de choses à rechercher? Par exemple, je n'ai vu aucune liste mentionner que l'exécution DISABLE KEYSsur une table InnoDB enverra un avertissement, à l'exception de la page de manuel pour ALTER TABLE. C'est ce genre de chose que je dois savoir avant de convertir. Je pensais que je serais d'accord avec mes requêtes mais apparemment pas.

Voici quelques pièges

Utilisation de la mémoire

MyISAM

• ne met en cache que les pages d'index.
• cache de clés partagé (dimensionné par key_buffer_size).
• Vous pouvez également configurer un cache de clés dédié, une ou plusieurs tables par table de cache .

InnoDB

• met en cache les pages de données et les pages d'index.
• un pool de mémoire tampon et une taille avant MySQL 5.5
• 1 ou plusieurs pools de tampons commençant par MySQL 5.5

Voici quelques requêtes que j'ai écrites et publiées plus tôt sur la façon de choisir une taille appropriée pour le cache de clés MyISAM et le pool de tampons InnoDB .

Index FULLTEXT

MyISAM

• Prend en charge les index FULLTEXT

InnoDB

• À partir de MySQL 5.6, oui, mais toujours en version bêta (MISE À JOUR: MySQL 5.6 existe et possède des index FULLTEXT. Si vous utilisez l'indexation FULLTEXT dans MySQL 5.6, assurez-vous que vous utilisez les options FULLTEXT spécifiques à InnoDB )
• Avant MySQL 5.6, cela signifie que vous ne pouvez pas convertir MyISAM en InnoDB.

MySQL 5.5 et arrière

Pour localiser les tables MyISAM ayant un index FULLTEXT, exécutez cette requête:

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);

Tout ce qui sort de cette requête ne peut pas être converti en InnoDB avant la mise à niveau vers MySQL 5.6.

OPTIMISER LA TABLE

MyISAM

• La table MyISAM est réduite
• ANALYZE TABLE exécute des statistiques d'index sur tous les index

InnoDB

• ANALYZE TABLE est totalement inutile car les statistiques d'index sont toujours en mémoire
• Avec innodb_file_per_table désactivé, ibdata1 s'agrandira
• Avec innodb_file_per_table activé, le fichier d'espace de table (.ibd) est réduit

Je pense que le plus gros problème serait que innodb est transactionnel. Vous voudrez savoir si les bibliothèques MySQL utilisées par vos applications auto_commit par défaut ou non.

Python , par exemple, ne se valide pas automatiquement. Cela signifie que si une application insérait une ligne juste avant de fermer sa connexion, l'insertion serait désormais annulée après la modification de innodb. Le script python par exemple devrait être sûr d'appeler connection.commit ();

Un autre point de différence pourrait être autour des insertions ou des mises à jour sur plusieurs lignes. Envisagez une seule insertion à plusieurs lignes

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

Considérez ce qui se passe s'il y a une sorte d'erreur telle qu'une collision de clés unique sur row3. Avec MyISAM, les deux premières lignes auraient été écrites, sous innodb, toutes les lignes en cours d'écriture seraient annulées, ne laissant rien d'écrit même après une telle erreur.

Avec innodb, vous entrerez dans le monde des impasses. Ceux-ci ne sont pas intrinsèquement mauvais, sauf s'ils surviennent à une telle fréquence pour empêcher tout travail d'être effectué. Cependant, vos applications devront être codées de telle manière qu'elles anticipent les blocages et les gèrent de manière appropriée (ce qui signifie très probablement simplement réessayer).

Tenez compte des limitations de mémoire / stockage. Innodb consomme beaucoup plus de ressources que MyISAM. Si vous avez suffisamment de RAM pour garder vos pools de mémoire tampon suffisamment grands pour accueillir toutes vos tables, vous êtes en or.

Recherchez les tables qui ont de grandes clés primaires. L'indexation en cluster d'Innodb signifie que chaque index secondaire contient une autre copie du PK de la ligne correspondante. Si vous avez 2 index secondaires, cela signifie que chaque ligne PK est stockée 3 fois (PK + chaque index). Si le pk s'étend sur plusieurs colonnes et types de données volumineux (char (N) par exemple), vous pouvez voir comment les exigences d'index peuvent exploser rapidement sous innodb.