Nonobstant les avantages / inconvénients de son utilisation, qui sont discutés dans d'autres discussions ( MyISAM contre InnoDB ), la migration est un processus non trivial.
Considérez
- Tester fonctionnellement tous les composants qui communiquent avec la base de données si possible :les moteurs de différence ont une sémantique différente
- Effectuez autant de tests de performances que possible :certaines choses peuvent s'améliorer, d'autres peuvent être bien pires. Un exemple bien connu est SELECT COUNT(*) sur une grande table.
- Vérifier que tout votre code gérera les interblocages avec élégance :vous pouvez les obtenir sans utiliser explicitement de transactions
- Estimez l'utilisation de l'espace que vous obtiendrez en effectuant la conversion :testez-la dans un environnement hors production.
Vous aurez sans doute besoin de changer les choses dans une grande plate-forme logicielle; c'est correct, mais étant donné que vous avez (espérons-le) une grande couverture de test automatique, le changement devrait être acceptable.
PS :Si "Quelque chose commence à taxer le CPU", alors vous devriez a) Découvrir quoi, dans un environnement de non-production, b) Essayer diverses options pour le réduire, dans un environnement de non-production. Vous ne devriez pas commencer aveuglément à faire des choses importantes comme changer de moteur de base de données alors que vous n'avez pas complètement analysé le problème.
Tous les tests de performances doivent être effectués dans un environnement hors production, avec des données de type production et sur du matériel de qualité production. Sinon, il est difficile d'interpréter correctement les résultats.
