Quelles tables devraient ou pourraient être migrées vers InnoDB, et lesquelles devraient rester MyISAM?

Selon le titre: Existe-t-il une liste rapide de candidats pour les tables à migrer vers InnoDB? Et ce qui devrait rester MyISAM.

Quelques informations supplémentaires

• Le site a une charge de lecture assez lourde, mais insère environ 10 nœuds par heure, avec des balises et autres.
• Nous utilisons beaucoup CCK (une énorme quantité de tables normalisées sous forme de content_field%).
• Nous utilisons également des vues pour tous nos blocs et pages; mais beaucoup d'entre eux sont susceptibles d'être remplacés par des modules personnalisés (afin de réduire les requêtes de base de données et la lourdeur de ces requêtes).
• Les utilisateurs sont tous anonymes; à l'exception de quelques éditeurs et webmasters connectés.

Vous devez convertir toutes les données en InnoDB pour éviter les problèmes de verrouillage de table. Cependant, voici quelques éléments de réflexion:

Indexation FULLTEXT

À l'heure actuelle, seul MyISAM prend en charge l'indexation FULLTEXT. L'indexation FULLTEXT pour InnoDB est actuellement en cours de développement pour MySQL 5.6 mais n'est pas prête pour la production . Si vous avez des tables Drupal qui ont des index FULLTEXT, elles ne peuvent pas être converties en InnoDB pour le moment.

MISE À JOUR sur l'indexation FULLTEXT

MySQL 5.6 est maintenant GA (disponible pour une utilisation en production). Veuillez essayer l'indexation FULLTEXT dans InnoDB.

Pour localiser les tables qui ont un FULLTEXTindex, exécutez cette requête:

SELECT table_schema,table_name
FROM information_schema.statistics
WHERE index_type='FULLTEXT';

Si aucune ligne ne revient, convertissez toutes les tables InnoDB au contenu de votre cœur. J'ai écrit un article précédent sur la façon de convertir toutes les tables MyISAM en InnoDB en utilisant uniquement mysql .

Réplication MySQL

Si vous avez un environnement lourd en lecture, les lectures peuvent aller plus vite dans MyISAM si vous procédez comme suit:

• Configuration de la réplication maître / esclave
• Créez un ou plusieurs esclaves de lecture sous le maître
• Ajouter --skip-innodbdans /etc/my.cnf sur tous les esclaves (convertit les tables en MyISAM lors du chargement des données dans l'esclave)
• Changez le format de ligne de toutes les tables MyISAM sur chaque esclave en FIXE par cette commande: ALTER TABLE tblname ROW_FORMAT=FIXED;
• J'ai publié quelque chose à ce sujet dans le DBA StackExchange
• Le livre MySQL Database Design and Tuning recommande l'utilisation ROW_FORMAT=FIXEDaux pages 72,73. Cela convertira en interne tous les champs VARCHAR en CHAR. Cela rendra la table MyISAM plus grande, mais les SELECT exécutés par rapport à celle-ci seront beaucoup plus rapides. Je peux personnellement témoigner de cela. J'ai eu une fois une table de 1,9 Go. J'ai changé le format avec ALTER TABLE tblname ROW_FORMAT=FIXED. Le tableau a fini par 3,7 Go. La vitesse des SELECTs par rapport à elle était 20-25% plus rapide sans amélioration ou changement d'autre chose.

Le seul casse-tête avec cela est de rendre votre application consciente des esclaves de lecture séparés.

ÉPILOGUE

Si vous recherchez d'autres avantages pour chaque moteur de stockage, consultez le DBA StackExchange:

• Apr 14, 2011: Quelles sont les principales différences entre InnoDB et MyISAM?
• Sep 20, 2011: Le meilleur de MyISAM et InnoDB
• May 02, 2012: Quel moteur de stockage mysql choisir?
• May 03, 2012: Quel est le plus rapide, InnoDB ou MyISAM?

Étant donné que votre site Web est lourd en lecture, je convertirais simplement toutes les tables en InnoDB. Vous pourrez ensuite optimiser les performances de lecture en dimensionnant le pool de tampons InnoDB et le cache de requêtes de manière appropriée. De cette façon, nous réalisons plusieurs milliers de requêtes par seconde sur les serveurs de bases de données dédiés de notre infrastructure d'hébergement Drupal.