Comment choisissez-vous un moteur de base de données MySQL

En particulier, comment choisissez-vous entre MyISAM et InnoDB, quand aucune des fonctionnalités requises ne manque (par exemple, vous n'avez pas besoin de clés étrangères).

Cela revient-il toujours à essayer les deux et à mesurer? Ou existe-t-il de bonnes règles empiriques concernant le nombre et la fréquence des lectures par rapport aux écritures, et d'autres mesures de ce genre? La taille de la table a-t-elle un effet sur le choix type?

La réponse est que vous devez toujours mesurer, de préférence avec vos propres données et charge de travail si possible.

Étant donné que les modèles d'accès aux données peuvent varier considérablement d'une application à l'autre, il est difficile de dire et, selon toute probabilité, impossible de déterminer un «meilleur» moteur de stockage pour toutes les charges de travail.

Cependant, il y a des développements très encourageants dans l'espace MySQL ayant assisté à MySQLConf / Percona Performance Conf la semaine dernière.

Certains des moteurs de stockage alternatifs:

1. XtraDB (fork d'InnoDB)
2. Plugin InnoDB
3. PBXT
4. TokuDB

De plus, Percona, Google, etc. ont fourni des correctifs qui contribuent grandement aux performances d'InnoDB. Personnellement, je lance une version OurDelta. Cela fonctionne bien pour moi et j'encourage à vérifier les versions OurDelta et Percona.

S'il ne s'agit que d'un simple système de stockage / rapport, j'utilise MyISAM pour ses performances brutes.

J'utiliserais InnoDB si j'étais préoccupé par plusieurs accès simultanés avec beaucoup d'écritures, pour profiter du verrouillage au niveau de la ligne.

Il existe un bon nombre de références pour différents moteurs de base de données MySQL. Il y en a un décent comparant MyISAM, InnoDB et Falcon sur le blog Percona MySQL Performance , voir ici .

Une autre chose à considérer entre les deux moteurs susmentionnés (MyISAM et InnoDB) est leur approche du verrouillage. MyISAM effectue le verrouillage de table, tandis qu'InnoDB effectue le verrouillage de ligne. Il y a une variété de choses à considérer, pas seulement des chiffres de performance.

Il existe des fonctionnalités que vous trouverez très utiles, pour des raisons opérationnelles, même si votre application n'en a pas absolument besoin:

• InnoDB a MVCC, ce qui signifie que vous pouvez effectuer des sauvegardes cohérentes non bloquantes
• InnoDB a une récupération automatique, ce qui signifie qu'il n'y a pas de longues opérations de RÉPARATION DE TABLE après un arrêt impur
• Avec InnoDB, les lecteurs ne bloquent jamais les écrivains et vice versa, ce qui signifie (généralement) une plus grande simultanéité (cela ne signifie pas pour autant de meilleures performances dans le cas général)
• InnoDB regroupe ses lignes sur la clé primaire, ce qui PEUT signifier moins d'opérations d'E / S pour les opérations de lecture SI la clé primaire a été choisie suffisamment bien.

Donc, malgré les contraintes de clé étrangère, vous voudrez probablement utiliser InnoDB de toute façon.

bien sûr, c'est ServerFault, pas Stack Overflow, donc la bonne réponse est:

• Vous devez toujours utiliser le moteur que les développeurs d'applications ont choisi
• S'ils n'ont pas choisi un moteur spécifique, ils ne sont pas très sérieux au sujet de l'utilisation de MySQL, et ne savent probablement pas comment l'utiliser correctement.
• Vous ne pouvez pas passer à un moteur différent de celui sur lequel votre application a été testée, cela peut introduire des bogues.

Mon hébergeur nous a conseillé de nous débarrasser complètement de MyISAM et de passer à InnoDB, sauf si cela n'est pas possible.

Dans notre cas, nous avions une corruption de données grave qui commençait à apparaître de quelques fois à quelques fois par jour, nécessitant toujours REPAIR TABLE et les commandes associées, ce qui prenait du temps sur de grandes tables.

Une fois que nous avons converti (ou: avons été convertis) en InnoDB, les problèmes ont disparu instantanément. Inconvénients / mises en garde que nous avions:

• Impossible de convertir les tables avec l'index FULLTEXT (ce problème a disparu avec le temps par lui-même; il a été remplacé par une solution basée sur Solr / Lucene qui a de toute façon une bien meilleure qualité)
• Les grandes tables avec des millions de lignes qui nécessitent souvent COUNT (*) étaient très lentes, nous n'avons pas pu les changer non plus.

Mais notez: tout cela est spécifique à notre environnement, etc., donc cela peut ne pas s'appliquer généralement.