Quelles sont les principales différences entre InnoDB et MyISAM?

Question

poelinca · Answer

La première différence majeure que je vois est que InnoDB implémente un verrouillage au niveau ligne alors que MyISAM ne peut effectuer qu'un verrouillage au niveau table. Vous trouverez une meilleure récupération après incident dans InnoDB. Cependant, il n'a pas d'index de recherche FULLTEXT jusqu'à la version 5.6, tout comme MyISAM. InnoDB implémente également les transactions, les clés étrangères et les contraintes de relation, contrairement à MyISAM.

La liste peut aller un peu plus loin. Pourtant, ils ont tous deux leurs avantages uniques en leur faveur et leurs inconvénients. Chacun d'eux est plus adapté dans certains scénarios que l'autre.

Donc, pour résumer (TL; DR):

InnoDB dispose d'un verrouillage au niveau des lignes, MyISAM ne peut effectuer qu'un verrouillage complet au niveau de la table.
InnoDB a une meilleure récupération après incident.
MyISAM a FULLTEXT index de recherche, InnoDB ne l'a pas avant MySQL 5.6 (février 2013).
InnoDB implémente les transactions, les clés étrangères et les contraintes de relation, pas MyISAM.

RolandoMySQLDBA · Answer

Une autre différence majeure non encore mentionnée est la façon dont la mise en cache pour chaque moteur de stockage est effectuée.

[~ # ~] myisam [~ # ~]

Le principal mécanisme utilisé est le cache de clés. Il ne met en cache que les pages d'index des fichiers .MYI. Pour dimensionner votre cache de clés, exécutez la requête suivante:

SELECT CONCAT(ROUND(KBS/POWER(1024, IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999), SUBSTR(' KMG',IF(PowerOf1024<0,0, IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_key_buffer_size FROM (SELECT LEAST(POWER(2,32),KBS1) KBS FROM (SELECT SUM(index_length) KBS1 FROM information_schema.tables WHERE engine='MyISAM' AND table_schema NOT IN ('information_schema','mysql')) AA ) A, (SELECT 2 PowerOf1024) B;

Cela donnera le paramètre recommandé pour MyISAM Key Cache ( key_buffer_size ) compte tenu de votre ensemble de données actuel ( la requête plafonnera la recommandation à 4G (4096M). Pour un système d'exploitation 32 bits, 4 Go est la limite. Pour 64 bits, 8 Go.

InnoDB

Le principal mécanisme utilisé est le pool de tampons InnoDB. Il met en cache les données et les pages d'index des tables InnoDB accessibles. Pour dimensionner votre pool de tampons InnoDB, exécutez la requête suivante:

SELECT CONCAT(ROUND(KBS/POWER(1024, IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999), SUBSTR(' KMG',IF(PowerOf1024<0,0, IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables WHERE engine='InnoDB') A, (SELECT 2 PowerOf1024) B;

Cela donnera le paramètre recommandé pour la taille du pool de tampons InnoDB ( innodb_buffer_pool_size ) compte tenu de votre ensemble de données actuel.

N'oubliez pas de redimensionner les fichiers journaux InnoDB (ib_logfile0 et ib_logfile1). Le code source MySQL place un plafond des tailles combinées de tous les fichiers journaux InnoDB doivent être <4G (4096M). Dans un souci de simplicité, étant donné que deux fichiers journaux seulement, voici comment vous pouvez les dimensionner:

Étape 1) Ajoutez innodb_log_file_size = NNN à /etc/my.cnf (NNN doit représenter 25% de innodb_buffer_pool_size ou 2047M, selon la plus petite des deux)
Étape 2) service mysql stop
Étape 3) rm /var/log/mysql/ib_logfile[01]
Étape 4) service mysql start (ib_logfile0 et ib_logfile1 sont recréés)

[~ # ~] mise en garde [~ # ~]

À la fin des deux requêtes se trouve une requête en ligne (SELECT 2 PowerOf1024) B

(SELECT 0 PowerOf1024) donne le paramètre en octets
(SELECT 1 PowerOf1024) donne le paramètre en kilo-octets
(SELECT 2 PowerOf1024) donne le paramètre en mégaoctets
(SELECT 3 PowerOf1024) donne le paramètre en gigaoctets
Aucun pouvoir inférieur à 0 ou supérieur à 3 n'est accepté

[~ # ~] épilogue [~ # ~]

Rien ne remplace le bon sens. Si vous avez une mémoire limitée, un mélange de moteurs de stockage ou une combinaison de ceux-ci, vous devrez vous adapter à différents scénarios.

Si vous avez 2 Go RAM et 16 Go d'InnoDB, allouez 512 Mo en tant que innodb_buffer_pool.
Si vous avez 2 Go RAM et 4 Go d'index MyISAM, allouez 512 Mo en tant que key_buffer_size.
Si vous avez 2 Go RAM et 4 Go d'index MyISAM et 16 Go InnoDB, allouez 512 Mo comme key_buffer_size et 512 Mo comme innodb_buffer_pool_size.

Les scénarios possibles sont infinis !!!

N'oubliez pas, quoi que vous allouiez, laissez suffisamment RAM pour les connexions DB et le système d'exploitation.

dabest1 · Answer

InnoDB propose:

Transactions ACID
verrouillage au niveau des lignes
contraintes de clé étrangère
reprise après incident automatique
compression de table (lecture/écriture)
types de données spatiales (pas d'index spatiaux)

Dans InnoDB, toutes les données consécutives, à l'exception de TEXT et BLOB, peuvent occuper 8 000 octets au maximum. L'indexation de texte intégral n'est pas disponible dans InnoDB avant MySQL 5.6 (février 2013). Dans InnoDB, la COUNT(*) s (lorsque WHERE, GROUP BY Ou JOIN n'est pas utilisée) s'exécute plus lentement que dans MyISAM car le nombre de lignes n'est pas stocké en interne . InnoDB stocke les données et les index dans un seul fichier. InnoDB utilise un pool de tampons pour mettre en cache les données et les index.

MyISAM propose:

fast COUNT(*) s (lorsque WHERE, GROUP BY ou JOIN n'est pas utilisé)
indexation en texte intégral (mise à jour: prise en charge dans InnoDB à partir de MySQL 5.6)
encombrement du disque plus petit
compression de table très élevée (lecture seule)
types de données spatiales et index (arborescence R) (mise à jour: prise en charge dans InnoDB à partir de MySQL 5.7)

MyISAM a un verrouillage au niveau de la table, mais pas de verrouillage au niveau des lignes. Aucune transaction. Pas de récupération automatique après incident, mais il offre une fonctionnalité de table de réparation. Aucune contrainte de clé étrangère. Les tables MyISAM sont généralement plus compactes sur le disque par rapport aux tables InnoDB. Les tables MyISAM pourraient être encore plus réduites en compressant avec myisampack si nécessaire, mais devenir en lecture seule. MyISAM stocke les index dans un fichier et les données dans un autre. MyISAM utilise des tampons clés pour la mise en cache des index et laisse la gestion de la mise en cache des données au système d'exploitation.

Dans l'ensemble, je recommanderais InnoDB pour la plupart des utilisations et MyISAM pour des utilisations spécialisées uniquement. InnoDB est désormais le moteur par défaut dans les nouvelles versions de MySQL.

d4nyll · Answer

Un peu tard pour le jeu ... mais voici un assez complet post que j'ai écrit il y a quelques mois , détaillant les principales différences entre MYISAM et InnoDB. Prenez une tasse de thé (et peut-être un biscuit) et dégustez.

La principale différence entre MyISAM et InnoDB réside dans l'intégrité référentielle et les transactions. Il existe également d'autres différences telles que le verrouillage, les restaurations et les recherches de texte intégral.

Intégrité référentielle

L'intégrité référentielle garantit que les relations entre les tables restent cohérentes. Plus précisément, cela signifie que lorsqu'une table (par exemple, les listes) a une clé étrangère (par exemple, l'ID de produit) pointant vers une table différente (par exemple, les produits), lorsque des mises à jour ou des suppressions se produisent dans la table pointée, ces modifications sont répercutées en cascade sur la liaison table. Dans notre exemple, si un produit est renommé, les clés étrangères de la table de liaison seront également mises à jour; si un produit est supprimé du tableau "Produits", toutes les listes qui pointent vers l'entrée supprimée seront également supprimées. En outre, toute nouvelle liste doit avoir cette clé étrangère pointant vers une entrée existante valide.

InnoDB est un SGBD relationnel (RDBMS) et a donc une intégrité référentielle, contrairement à MyISAM.

Transactions et atomicité

Les données d'une table sont gérées à l'aide d'instructions DML (Data Manipulation Language), telles que SELECT, INSERT, UPDATE et DELETE. Une transaction regroupe deux instructions DML ou plus en une seule unité d'oeuvre, de sorte que l'unité entière est appliquée, ou rien de tout cela.

MyISAM ne prend pas en charge les transactions, contrairement à InnoDB.

Si une opération est interrompue lors de l'utilisation d'une table MyISAM, l'opération est immédiatement abandonnée et les lignes (ou même les données de chaque ligne) qui sont affectées restent affectées, même si l'opération ne s'est pas terminée.

Si une opération est interrompue lors de l'utilisation d'une table InnoDB, parce qu'elle utilise des transactions, qui ont l'atomicité, toute transaction qui ne s'est pas terminée ne prendra pas effet, car aucune validation n'est effectuée.

Verrouillage de table vs verrouillage de ligne

Lorsqu'une requête s'exécute sur une table MyISAM, la table entière dans laquelle elle interroge sera verrouillée. Cela signifie que les requêtes suivantes ne seront exécutées qu'après la fin de la requête en cours. Si vous lisez un grand tableau et/ou si des opérations de lecture et d'écriture sont fréquentes, cela peut signifier un énorme arriéré de requêtes.

Lorsqu'une requête s'exécute sur une table InnoDB, seules les lignes impliquées sont verrouillées, le reste de la table reste disponible pour les opérations CRUD. Cela signifie que les requêtes peuvent s'exécuter simultanément sur la même table, à condition qu'elles n'utilisent pas la même ligne.

Cette fonctionnalité dans InnoDB est connue sous le nom de simultanéité. Aussi grande que soit la concurrence, il existe un inconvénient majeur qui s'applique à une plage sélectionnée de tables, en ce sens qu'il y a un surcoût lors du basculement entre les threads du noyau, et vous devez définir une limite sur les threads du noyau pour empêcher le serveur de s'arrêter .

Transactions et annulations

Lorsque vous exécutez une opération dans MyISAM, les modifications sont définies; dans InnoDB, ces modifications peuvent être annulées. Les commandes les plus courantes utilisées pour contrôler les transactions sont COMMIT, ROLLBACK et SAVEPOINT. 1. COMMIT - vous pouvez écrire plusieurs opérations DML, mais les modifications ne seront enregistrées que lorsqu'un COMMIT est effectué 2. ROLLBACK - vous pouvez ignorer toutes les opérations qui n'ont pas encore été validées 3. SAVEPOINT - définit un point dans la liste des opérations auxquelles une opération ROLLBACK peut revenir en arrière

Fiabilité

MyISAM n'offre aucune intégrité des données - Les pannes matérielles, les arrêts impurs et les opérations annulées peuvent endommager les données. Cela nécessiterait une réparation complète ou des reconstructions des index et des tables.

InnoDB, d'autre part, utilise un journal des transactions, un tampon de double écriture et une somme de contrôle et une validation automatiques pour éviter la corruption. Avant qu'InnoDB n'apporte des modifications, il enregistre les données avant les transactions dans un fichier d'espace disque logique système appelé ibdata1. En cas de plantage, InnoDB récupère automatiquement via la relecture de ces journaux.

Indexation FULLTEXT

InnoDB ne prend pas en charge l'indexation FULLTEXT jusqu'à MySQL version 5.6.4. Au moment de la rédaction de cet article, la version de MySQL de nombreux hébergeurs partagés est toujours inférieure à 5.6.4, ce qui signifie que l'indexation FULLTEXT n'est pas prise en charge pour les tables InnoDB.

Cependant, ce n'est pas une raison valable pour utiliser MyISAM. Il est préférable de passer à un fournisseur d'hébergement qui prend en charge les versions à jour de MySQL. Cela ne signifie pas qu'une table MyISAM qui utilise l'indexation FULLTEXT ne peut pas être convertie en table InnoDB.

Conclusion

En conclusion, InnoDB devrait être votre moteur de stockage par défaut de choix. Choisissez MyISAM ou d'autres types de données lorsqu'ils répondent à un besoin spécifique.

Gaius · Answer

Encore une chose: vous pouvez sauvegarder les tables InnoDB simplement en prenant un instantané du système de fichiers. La sauvegarde de MyISAM nécessite l'utilisation de mysqldump et n'est pas garantie d'être cohérente (par exemple, si vous insérez dans une table parent et enfant, vous ne trouverez peut-être que la ligne de la table enfant dans votre sauvegarde).

Fondamentalement, si vous avez une autre copie des données et que vous ne la cachez que dans MySQL, par exemple pour permettre un moyen standard d'y accéder à partir d'un site Web PHP, alors MyISAM est correct (c'est-à-dire qu'il vaut mieux qu'un fichier CSV plat ou un fichier journal pour les requêtes et les accès simultanés). Si la base de données est la "copie maîtresse" réelle des données, si vous faites INSERT et UPDATE en utilisant de vraies données d'utilisateurs, alors il est stupide d'utiliser autre chose qu'InnoDB, à n'importe quelle échelle MyISAM est peu fiable et difficile à gérer, vous ferez myisamchk la moitié du temps, annulant tout gain de performances ...

(Mon expérience personnelle: une base de données de 2 téraoctets dans MyISAM).

bsoist · Answer

D'après mon expérience, la différence la plus importante est la façon dont chaque moteur gère le verrouillage. InnoDB utilise le verrouillage de ligne tandis que MyISAM utilise le verrouillage de table. En règle générale, j'utilise InnoDB pour écrire des tables lourdes et MyISAM pour lire des tables lourdes.

D'autres différences importantes comprennent:

InnoDB prend en charge les transactions et les clés étrangères. MyISAM ne le fait pas.
MyISAM utilise l'indexation de texte intégral.
MyISAM fait un mauvais travail pour faire respecter l'intégrité des données.

Patrick · Answer

J'ai tendance à considérer MyISAM comme le choix de table "par défaut" pour MySQL, je vais donc souligner les différences pour la plupart des utilisateurs d'InnoDB

Verrouillage de niveau de ligne
Application des clés étrangères
Prise en charge des transactions
Baisse des performances des systèmes à haute utilisation

Mahesh Patil · Answer

Inclut les modifications MySQL 5.6

MOTEUR DE STOCKAGE INNODB:

Il fournit une conformité ACID complète (atomicité, cohérence, isolation, durabilité). Le multi-version est utilisé pour isoler les transactions les unes des autres.
InnoDB fournit une récupération automatique après un crash du serveur MySQL ou de l'hôte sur lequel le serveur s'exécute.
InnoDB prend en charge les clés étrangères et l'intégrité référentielle, y compris les suppressions et les mises à jour en cascade.
MySQL 5.6 s'appuie sur la plateforme d'InnoDB entièrement intégrée en tant que moteur de stockage par défaut
Persistent Optimizer Stats: Fournit une précision améliorée des statistiques d'index InnoDB et une cohérence entre les redémarrages de MySQL.
Élagage du cache de table InnoDB: Pour alléger la charge mémoire sur les systèmes avec un grand nombre de tables, InnoDB libère désormais la mémoire associée à une table ouverte. Un algorithme LRU sélectionne les tables qui ont duré le plus longtemps sans être accessibles.
Prend en charge la recherche en texte intégral: Un type d'index spécial, l'index FULLTEXT, aide InnoDB à traiter les requêtes et les opérations DML impliquant des colonnes textuelles et les mots qu'elles contiennent. Ces index sont physiquement représentés sous forme de tables InnoDB entières.
InnoDB semble être beaucoup plus rapide sur la recherche en texte intégral que MyISAM

Il est donc inutile d'utiliser MyISAM Engine si vous êtes déjà mis à niveau vers 5.6, sinon n'attendez pas la mise à niveau vers MySQL 5.6.

Performances InnoDB VS MyISAM utilisant MySQL 5.6

Anto · Answer

MYISAM

MYISAM fournit le verrouillage au niveau de la table, la recherche FULLTEXT. MYISAM possède la colonne AUTO_INCREMENTED la plus flexible qui gère tous les moteurs de stockage. MYISAM ne prend pas en charge les transactions.

INNODB

INNODB est un moteur de stockage sécurisé pour les transactions. INNODB dispose de capacités de validation, de restauration et de récupération après incident. INNODB prend en charge l'intégrité référentielle des clés étrangères.

wogsland · Answer

MyISAM

MyISAM est un moteur de stockage pour MySQL. Avant MySQL 5.5, c'était le moteur de stockage par défaut pour MySQL. Il est basé sur l'ancien moteur de stockage ISAM. MyISAM est optimisé pour les environnements avec des opérations de lecture lourdes et peu d'écritures, voire aucune. La raison pour laquelle MyISAM autorise des lectures rapides est la structure de son index: chaque entrée pointe vers un enregistrement dans le fichier de données et le pointeur est décalé depuis le début du fichier. De cette façon, les enregistrements peuvent être lus rapidement, en particulier lorsque le format est FIXE. Ainsi, les lignes sont de longueur constante. zone typique dans laquelle on pourrait préférer MyISAM est l'entrepôt de données, car il implique des requêtes sur de très grandes tables, et la mise à jour de ces tables se fait lorsque la base de données n'est pas utilisée (généralement la nuit). Les insertions sont également faciles, car de nouvelles lignes sont ajoutés à la fin du fichier de données. Cependant, les opérations de suppression et de mise à jour sont plus problématiques: les suppressions doivent laisser un espace vide, ou les décalages des lignes changeraient; il en va de même pour les mises à jour, car la longueur des lignes devient plus courte; si la mise à jour rallonge la ligne, la ligne est fragmentée. ent des lignes et réclamer un espace vide, la commande OPTIMIZE TABLE doit être exécutée. En raison de ce mécanisme simple, les statistiques d'index MyISAM sont généralement assez précises. D'autres inconvénients majeurs de MyISAM sont l'absence de prise en charge des transactions et des clés étrangères.

InnoDB

InnoDB est un moteur de stockage pour MySQL. MySQL 5.5 et versions ultérieures l'utilisent par défaut. Il fournit les fonctionnalités de transaction conformes à ACID standard, ainsi que la prise en charge des clés étrangères (intégrité référentielle déclarative). Il implémente à la fois les transactions SQL et XA, les espaces disque logiques, les index FULLTEXT et les opérations spatiales suivant la norme OpenGIS. Il est inclus en standard dans la plupart des binaires distribués par MySQL AB, à l'exception de certaines versions OEM. Le logiciel est sous double licence par Oracle Corporation; il est distribué sous la licence GNU General Public License, mais peut également être concédé sous licence aux parties souhaitant combiner InnoDB dans un logiciel propriétaire.

Fourches

MariaDB a un moteur de stockage appelé Aria, qui est décrit comme une "alternative sûre à MyISAM". MariaDB et Percona Server utilisent par défaut un fork d'InnoDB appelé XtraDB. XtraDB est maintenu par Percona. Les modifications d'Oracle InnoDB sont régulièrement importées dans XtraDB, et certaines corrections de bugs et fonctionnalités supplémentaires sont ajoutées.