Y a-t-il des pièges / choses que vous devez savoir lorsque vous passez de MyISAM à InnoDB

Question

L’un de mes projets utilise le moteur MyISAM dans MySQL, mais j’envisage de le remplacer par InnoDB car j’ai besoin d’un support pour les transactions ici et là.

• Que dois-je regarder ou considérer avant de faire ceci?
• Puis-je simplement changer le moteur, ou faut-il que les données soient préparées?

Answer 1

Oui, absolument, il y a beaucoup de choses, vous devriez tester votre application de manière extrêmement approfondie:

• Les transactions peuvent être dans une impasse et doivent être répétées. C’est le cas (dans certaines circonstances) même avec une transaction auto-validée qui n’insère qu’une seule ligne.
• L'utilisation du disque va presque certainement augmenter
• La charge d'E / S au cours de l'écriture augmentera presque certainement
• Le comportement de l'indexation va changer car InnoDB utilise des index clusterisés - cela peut être bénéfique dans certains cas
• Votre stratégie de sauvegarde sera impactée. Considérez ceci attentivement.

Le processus de migration lui-même devra être planifié avec soin, car cela prendra beaucoup de temps si vous avez beaucoup de données (pendant lesquelles les données seront soit en lecture seule, soit totalement indisponibles - vérifiez!)

Answer 2

Il y a une grosse mise en garde. Si vous rencontrez un type de défaillance matérielle (ou similaire) lors d’une écriture, InnoDB corrompra les tables.

MyISAM le fera aussi, mais un mysqlcheck --auto-repair les réparera. Essayer cela avec les tables InnoDB échouera. Oui, c'est par expérience.

Cela signifie que vous devez disposer d’un bon plan de sauvegarde des données pour pouvoir utiliser InnoDB.

Answer 3

Quelques autres notes:

InnoDB ne réalloue pas l’espace libre sur le système de fichiers après l’abandon d’une table / base de données ou la suppression d’un enregistrement, ce problème peut être résolu en effectuant un "dumping et une importation". ou en définissant innodb_file_per_table = 1 dans my.cnf.

L'ajout / la suppression d'index sur une grande table InnoDB peut être très pénible, car elle verrouille la table actuelle, en crée une temporaire avec vos index modifiés et insère des données, ligne par ligne. Il existe un plug-in de Innobase , mais cela fonctionne. uniquement pour MySQL 5.1

InnoDB est aussi BEAUCOUP PLUS intense en mémoire, je vous suggère donc d'avoir une variable innodb_buffer_pool_size aussi large que le permet la mémoire de votre serveur (70-80% devrait constituer une valeur sûre). Si votre serveur est UNIX / Linux, envisagez de réduire la variable sysctl vm.swappiness à 0 et utilisez innodb_flush_method = O_DIRECT pour éviter la double mise en tampon. Testez toujours si vous appuyez sur swap lors du basculement de ces valeurs. Vous pouvez toujours en lire plus à blog Percona , ce qui est excellent.

De plus, vous pouvez exécuter mysqlbackup avec - transaction unique --skip-lock-tables et ne pas avoir de verrou de table pendant le début de la sauvegarde.

En tout cas, InnoDB est génial, ne laissez pas certains pièges vous décourager.

Answer 4

Il suffit de modifier le tableau et de régler le moteur.

• L’un des gros problèmes à surveiller est que le nombre de sélections (*) de MyTable est beaucoup plus lent dans InnoDB que dans MyISAM.
  
• Les valeurs auto_increment réinitialiseront la valeur la plus élevée du tableau +1 après le redémarrage du serveur. Cela peut entraîner de drôles problèmes si vous avez une base de données désordonnée avec certaines suppressions.
• Les paramètres de serveur optimaux seront différents de la base de données principalement MyISAM.
• Assurez-vous que la taille du fichier innodb est suffisamment grande pour contenir toutes vos données, sinon vous serez crucifié par une réallocation constante lorsque vous modifiez les moteurs des tables.

Answer 5

Si vous souhaitez utiliser InnoDB pour obtenir des requêtes simultanées, vous devez définir innodb_file_trx_commit = 1 afin d'obtenir des performances en retour. OTOH, si vous souhaitez re-coder votre application pour qu'elle prenne en compte les transactions, le choix de ce paramètre fera partie de l'évaluation des performances générale des paramètres InnoDB.

L’autre grande chose à surveiller est qu’InnoDB ne prend pas en charge les index FullText, ni INSERT DELAYED. Mais alors, MyISAM ne supporte pas l’intégrité référentielle. : -)

Cependant, vous ne pouvez déplacer que les tables dont vous avez besoin de connaître les transactions. J'ai fait ça. Les petites tables (jusqu’à plusieurs milliers de lignes) peuvent souvent être modifiées à la volée.

Answer 6

Les performances peuvent être différentes, vous devrez donc peut-être surveiller la charge.

Les données iront bien.