Les différents moteurs de stockage de MySQL

Les tables de type Memory enregistrent les données dans la mémoire vive de la machine (RAM), d'où un gain considérable de rapidité pour accéder aux informations.

Le moteur Memory est extrêmement utile pour les tables très souvent sollicitées.
Attention tout de même : il serait facile de se dire que parce que nous avons beaucoup de RAM, nous pouvons passer toutes les tables en Memory ; ce n'est hélas pas si simple, car il y a aussi des inconvénients. En effet, seule la structure des tables est stockée dans des fichiers, alors que les données ne le sont qu'en mémoire. Si la machine s'arrête ou que le service de MySQL redémarre, vous perdez tous vos enregistrements.

Il est possible lors du démarrage du serveur avec l'option init-file ou dans le fichier de configuration, ou encore par ligne de commande, de remplir les tables Memory. Dès lors, vous pouvez mettre les commandes INSERT INTO, SELECT et LOAD DATA INFILE afin de lire des enregistrements d'une source de données persistante (fichier ou table d'un autre moteur).

Pour des raisons de sécurité du serveur, il est possible de déterminer la taille maximale allouée aux tables par la variable système max_heap_table_size. Vous pouvez aussi, lors de la création de la table, indiquer le nombre maximum d'enregistrements via la clause MAX_ROWS.
Une table Memory ne peut être transformée en table physique par la commande ALTER, contrairement à celles des autres moteurs.

Pour libérer de la mémoire, il suffit simplement d'exécuter les commandes DELETE, TRUNCATE ou DROP heap_table.

Il faut vous mettre en garde dans le cas où vous êtes dans un hébergement mutualisé.
Beaucoup d'hébergeurs proposent ce moteur de base de données, mais il est rarement possible d'accéder au fichier de configuration de MySQL pour gérer la limite de la mémoire, ni le chargement des données au démarrage du serveur. Il y a une astuce qui consiste à utiliser une requête de copie.
Pour cela, il faut avoir une table de type MyISAM (ou tout autre type de table physique) de même structure que la table Memory. La requête est :

INSERT INTO maTableMemory SELECT * maTableMySIAM

Cette astuce n'est pas optimisée ni très pratique car il faut vérifier fréquemment le contenu de la table Memory. Il est aussi possible de passer par un trigger qui peut vérifier l'existence de contenu de la table Memory.

• Enorme gain de rapidité.
• Couramment proposé chez les hébergeurs en mutualisé mais...

• Nécessité d'avoir accès au fichier de configuration de MySQL chez les hébergeurs en mutualisé.
• Perte des données en mémoire au redémarrage du serveur (même s'il existe une commande permettant de recharger les données, il faut être sûr qu'elles soient à jour dans le fichier de données.
• Impossibilité de transformer une table Memory en table physique (exemple : Memory vers MyIsam).
• Ne supporte pas les champs de type BLOB/TEXT, les champs AUTO_INCREMENT ainsi que les champs index n'étant pas en NOT NULL.
• Vue son utilisation, nécessite une quantité de mémoire RAM conséquente. Si la table utilise plus de mémoire que la machine en possède, l'OS va "swapper". Ce qui entraînera des performances bien plus mauvaises qu'avec l'utilisation d'une table physique.
• Possède les mêmes inconvénients que les tables MyISAM.

L'utilisation de ce moteur est très utile lorsque l'on a des données très souvent sollicitées et possédant une taille inférieure à la quantité de RAM disponible sur la machine. Un exemple d'utilisation pratique serait l'enregistrement d'objets sérialisés dans MySQL. Attention toutefois à ne pas dépasser la capacité de mémoire et de prévoir les redémarrages du serveur MySQL.