Le but ici est de comparer les types de tables MyISAM et InnoDB. Pour cela, nous avons pris une base de test que nous avons remplie au fur à et mesure avec du texte aléatoire, jusqu’à obtenir 1 000 000 d’enregistrements. C’est à partir de cette base que nous avons effectué les tests.

Pour commencer, voici donc le temps nécessaire pour remplir une base :

Table Enregistrements Temps
MyIsam 100 000 72sec
InnoDB 100 000 >2min
MyISAM 20 000 1.43 sec
InnoDB 20 000 105 sec

C’est indiscutable, InnoDB semble plus lent pour l’insertion des données. Et pourquoi donc ?! Il faut savoir que InnoDB est de type transactionnelle alors que MyISAM est (on s’en doute un peu) non-transactionnelle. Bon… Et ?! Ca veux dire quoi au juste ces termes barbares ?!

Les tables non-transactionnelles sont plus rapide, utilisent moins d’espace disque et moins de mémoire. Alors pourquoi choisir InnoDB ?! Car les tables transactionnelles sont plus sûr (en cas de crash de MySQL, vous pouvez tout de même récupérer vos données) et pour d’autres petits détails qui sortent un peu de cet article.

Les tables contiennent 4 champs :

Champ Type
Id bigint
Nom varchar(30), null autorisé
Prenom varchar(30) , null autorisé
Age Tinyint

Alors, nous voilà avec une table de 1 000 000 enregistrements (lignes) et nous allons pouvoir commencer les premiers tests. Juste pour info, voilà la place occupée par les différentes tables utilisées pour les tests (estimation de PhpMyAdmin, après optimisation) :

table index sur Nom Taille pour VACHAR(30 Taille pour CHAR(30)
MyISAM non 56.4Mo 194.9Mo
InnoDB non 60.6Mo 93.6Mo
MyISAM oui 61.8Mo 202Mo
InnoDB oui 104.2Mo 168.4Mo

On constate que InnoDB ne prend pas forcément plus de place que MyISAM. Mais cela tient surtout aux choix de stockage des données si vous choisissez plutôt CHAR que VARCHAR par exemple. Il faut bien garder à l’esprit que CHAR va allouer la taille indiqué (ici 30) quelque soit la quantité d’information stockée alors que VARCHAR va allouer la taille de l’information stockée (plus un reliquat pour indiqué la fin).

CHAR peut s’avérer plus rapide sur des tailles importantes (à partir de 100), mais n’a pratiquement aucune incidence en dessous.

Dans tous les tests que nous avons fait, le terme recherché, que ce soit un chiffre ou des lettres, est changé à chaque itération afin de ne pas récupérer un résultat dans un cache. Car, en effet, si MySQL reçoit une requête déjà effectuée, cette seconde requête (et les suivantes) est nettement plus rapide. La recherche est lancée plusieurs fois et le temps affiché est une moyenne. Les tests ont été relancés plusieurs fois à différents moments pour être certain que rien ne pouvait interférer sur les résultats.

Les tests

SELECT * FROM MaTable WHERE Age>45

Table Résultat
MyISAM 1.370
InnoDB 2.376

InnoDB est plus lent sur une requête simple.

SELECT * FROM MaTable WHERE Nom=’dummy’

Table Résultat
MyISAM 0.504
InnoDB 1.382

SELECT * FROM MaTable WHERE Nom<>‘dummy’

Table Résultat
MyISAM 1.996
InnoDB 3.163

La recherche par différence est plus longue que l’égalité.

SELECT * FROM MaTable WHERE Nom LIKE ‘xyz%’

Table Résultat
MyISAM 0.512
InnoDB 1.282

Aussi étonnant que cela puisse sembler, ici le temps est pratiquement le même pour une égalité pour un LIKE. Notons également que le temps reste le même si les données sont du type CHAR(30) ou VARCHAR(30).

SELECT * FROM MaTable WHERE Nom LIKE ‘xyz%’ ORDER BY Age

Table Résultat
MyISAM 0.484
InnoDB 1.409

Nous rajoutons un tri à la recherche. Du coup, InnoDB augmente un peu son temps alors que MyISAM le réduit.

Attention, maintenant, nous allons faire exactement la même requête, mais en ajoutant un index sur le champs Nom. Et là, vous allez voir que ce n’est pas négligeable d’y penser :

SELECT * FROM MaTable WHERE Nom LIKE ‘xyz%’ ORDER BY Age

Table Résultat
MyISAM 0.0005
InnoDB 0.002

Conclusion

Pas simple de conclure avec ces chiffres. Disons que si vous avez des informations importantes à stocker et que vous avez beaucoup d’utilisateurs qui vont faire des écritures simultanées dans votre base, il vaut peut-être mieux choisir InnoDB.

Si vous faites beaucoup de lecture de données et peu d’écriture, le choix doit se porter sur MyISAM.

Mettre un index sur un champs permet d’augmenter considérablement la vitesse lors d’une requête, mais augmente aussi la taille de la base. Faites donc attention surtout si vous êtes sur un serveur mutualisé.

Un dernier mot : il existe d’autres type de tables pour MySQL. Notamment les tables MEMORY. Mais ce type ne peut-être utilisé pour des tables de cette taille sans avoir une quantité de mémoire très importante. Nous effectuerons très certainement des tests dans un prochain article.