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

La première différence majeure que je vois est que InnoDB implémente un verrou au niveau de la ligne alors que MyISAM ne peut effectuer qu’un verrou au niveau de la table. Vous trouverez une meilleure récupération après incident dans InnoDB. Cependant, il n’a pas d’ FULLTEXTindex de recherche jusqu’à la v5.6, contrairement à MyISAM. InnoDB implémente également les transactions, les clés étrangères et les contraintes de relations, contrairement à MyISAM.

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

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

• InnoDB dispose d'un verrouillage au niveau de la ligne, MyISAM ne peut effectuer que le verrouillage complet au niveau de la table.
• InnoDB a une meilleure récupération après crash.
• MyISAM a FULLTEXTdes index de recherche, mais InnoDB ne le faisait pas avant MySQL 5.6 (février 2013).
• InnoDB implémente des transactions, des clés étrangères et des contraintes de relations, contrairement à MyISAM.

Une autre différence majeure non encore mentionnée concerne la manière dont la mise en cache est effectuée pour chaque moteur de stockage.

MYISAM

Le mécanisme principal utilisé est le cache de clé. 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 le cache de clé MyISAM ( key_buffer_size ) en fonction de votre ensemble de données actuel ( la requête plafonnera la recommandation à 4G (4096 M). Pour les systèmes d’exploitation 32 bits, la limite est de 4 Go . Pour les systèmes d’exploitation 32 bits, 8 Go.

InnoDB

Le mécanisme principal utilisé est le pool de mémoire tampon InnoDB. Il met en cache les données et les pages d'index des tables InnoDB auxquelles on a accédé. Pour dimensionner votre pool de mémoire tampon 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 mémoire tampon InnoDB ( innodb_buffer_pool_size ) en fonction 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 une limite des tailles combinées de tous les fichiers journaux InnoDB doit être <4G (4096M). Par souci de simplicité, pour seulement deux fichiers journaux, 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 valeur la plus petite).
• É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)

CAVEAT

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

• (SELECT 0 PowerOf1024) donne le réglage en octets
• (SELECT 1 PowerOf1024) donne le réglage en kilo-octets
• (SELECT 2 PowerOf1024) donne le réglage en mégaoctets
• (SELECT 3 PowerOf1024) donne le réglage en gigaoctets
• Aucune puissance inférieure à 0 ou supérieure à 3 n'est acceptée

ÉPILOGUE

Il n'y a pas de substitut au bon sens. Si vous avez une mémoire limitée, un mélange de moteurs de stockage ou une combinaison des deux, vous devrez vous adapter à différents scénarios.

• Si vous disposez de 2 Go de RAM et de 16 Go d’InnoDB, affectez 512 Mo à innodb_buffer_pool.
• Si vous disposez de 2 Go de RAM et de 4 Go d’index MyISAM, affectez 512 Mo à la valeur key_buffer_size.
• Si vous disposez de 2 Go de RAM, de 4 Go d’index MyISAM et de 16 Go d’InnoDB, allouez 512 Mo en tant que key_buffer_size et 512 M en tant que innodb_buffer_pool_size.

Les scénarios possibles sont infinis !!!

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

InnoDB offre:

• Transactions ACID
• verrouillage au niveau de la ligne
• contraintes de clé étrangère
• récupération automatique après incident
• compression de table (lecture / écriture)
• types de données spatiales (pas d'index spatial)

Dans InnoDB, toutes les données d’une ligne, à l’exception de TEXT et de BLOB, peuvent occuper au maximum 8 000 octets. L'indexation en texte intégral n'est pas disponible dans InnoDB jusqu'à la version 5.6 de MySQL (février 2013). Dans InnoDB, le COUNT(*)s (quand WHERE, GROUP BYou JOINn'est pas utilisé) 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 mémoire tampon pour mettre en cache les données et les index.

MyISAM offre:

• rapide COUNT(*)s (quand WHERE, GROUP BYou JOINest non utilisé)
• indexation de texte intégral (mise à jour: prise en charge dans InnoDB à partir de MySQL 5.6)
• encombrement réduit du disque
• très haute compression de table (lecture seule)
• types de données spatiales et index (arbre 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 de la ligne. 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 que les tables InnoDB. Les tables MyISAM pourraient être fortement réduites en compressant avec myisampack si nécessaire, mais deviendraient en lecture seule. MyISAM stocke les index dans un fichier et les données dans un autre. MyISAM utilise des tampons de clé pour la mise en cache des index et laisse la gestion de la mise en cache des données au système d'exploitation.

Globalement, je recommanderais InnoDB pour la plupart des objectifs et MyISAM pour des utilisations spécialisées uniquement. InnoDB est maintenant le moteur par défaut des nouvelles versions de MySQL.

Une dernière chose: vous pouvez sauvegarder les tables InnoDB en prenant simplement un instantané du système de fichiers. La sauvegarde de MyISAM nécessite l'utilisation de mysqldump et sa cohérence n'est pas garantie (par exemple, si vous insérez dans une table parent et une table enfant, vous risquez de ne trouver 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 mettez en cache que dans MySQL, par exemple pour autoriser un moyen standard d’y accéder depuis un site Web PHP, alors MyISAM convient (c’est-à-dire qu’il vaut mieux qu’un fichier CSV ou un fichier de log pour interroger et accès simultané). Si la base de données est la "copie maîtresse" réelle des données, si vous utilisez INSERTet UPDATEutilisez de vraies données d'utilisateurs, il est alors insensé d'utiliser autre chose que InnoDB, quelle que soit l'échelle utilisée. MyISAM n'est ni fiable, ni difficile à gérer. Je vais faire la myisamchkmoitié du temps, annulant tout gain de performance ...

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

Un peu tard dans le jeu ... mais voici un article assez complet 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 amusez-vous.

La principale différence entre MyISAM et InnoDB concerne 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 en texte intégral.

Intégrité référentielle

L'intégrité référentielle garantit la cohérence des relations entre les tables. Plus spécifiquement, cela signifie que lorsqu'une table (par exemple, les listes) a une clé étrangère (par exemple, un ID de produit) pointant vers une autre table (par exemple, des produits), lorsque des mises à jour ou des suppressions surviennent dans la table indiquée, ces modifications sont mises en cascade vers 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', toute liste qui pointe vers l'entrée supprimée sera également supprimée. En outre, toute clé nouvelle doit avoir cette clé étrangère pointant vers une entrée existante valide.

InnoDB est un SGBD relationnel (SGBDR) et présente 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 ou plusieurs instructions DML dans une même unité de travail. L'unité est donc appliquée dans sa totalité ou aucune.

MyISAM ne supporte pas les transactions contrairement à InnoDB.

Si une opération est interrompue lors de l'utilisation d'une table MyISAM, l'opération est immédiatement annulée et les lignes (ou même les données de chaque ligne) affectées restent affectées, même si l'opération n'a pas abouti.

Si une opération est interrompue lors de l’utilisation d’une table InnoDB, parce qu’elle utilise des transactions qui ont une atomicité, toute transaction qui n’a pas abouti n’est pas effective, car aucune validation n’est effectuée.

Verrouillage de table vs Verrouillage de rangée

Lorsqu'une requête s'exécute sur une table MyISAM, la table entière dans laquelle elle interroge est verrouillée. Cela signifie que les requêtes suivantes ne seront exécutées qu'à la fin de la requête en cours. Si vous lisez une grande table et / ou que les opérations de lecture et d'écriture sont fréquentes, cela peut entraîner un énorme retard dans le traitement des requêtes.

Lorsqu'une requête est exécutée 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 être exécutées simultanément sur la même table, à condition qu'elles n'utilisent pas la même ligne.

Cette fonctionnalité dans InnoDB est appelée simultanéité. Même si la concurrence est importante, il existe un inconvénient majeur qui s'applique à une plage sélectionnée de tables, en ce sens que la commutation entre les threads du noyau entraîne une surcharge, 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 couramment 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 sera effectué 2. ROLLBACK - vous pouvez ignorer toutes les opérations non encore 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 - Des pannes matérielles, des arrêts non nettoyés et des opérations annulées peuvent entraîner la corruption des données. Cela nécessiterait une réparation ou une reconstruction complète des index et des tables.

InnoDB, d’autre part, utilise un journal transactionnel, un tampon en double écriture et une vérification et une vérification automatiques pour prévenir la corruption. Avant d'apporter des modifications, InnoDB enregistre les données avant les transactions dans un fichier d'espace de table système appelé ibdata1. En cas de plantage, InnoDB effectuerait une récupération automatique via la relecture de ces journaux.

Indexation FULLTEXT

InnoDB ne prend pas en charge l'indexation FULLTEXT jusqu'à la version 5.6.4 de MySQL. Au moment de la rédaction de cet article, la version MySQL de nombreux fournisseurs d'hébergement partagé 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 faire appel à un fournisseur d'hébergement prenant en charge les versions les plus récentes de MySQL. Non pas qu'une table MyISAM qui utilise l'indexation FULLTEXT ne puisse être convertie en une table InnoDB.

Conclusion

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

D'après mon expérience, la différence la plus significative est la manière dont chaque moteur gère le verrouillage. InnoDB utilise le verrouillage des lignes tandis que MyISAM utilise le verrouillage des tables. En règle générale, j'utilise InnoDB pour écrire des tableaux lourds et MyISAM pour lire des tableaux lourds.

Les autres différences importantes incluent:

1. Les transactions de support InnoDB et les clés étrangères. MyISAM ne le fait pas.
2. MyISAM utilise l'indexation de texte intégral.
3. MyISAM ne parvient pas à faire respecter l'intégrité des données.

J'ai tendance à considérer MyISAM comme le choix de table 'par défaut' pour MySQL. Je soulignerai donc les différences entre la plupart des utilisateurs de InnoDB.

• Niveau de verrouillage de ligne
• Application de clé étrangère
• Support de transaction
• Performance atteinte sur les systèmes à forte utilisation

MYISAM

MYISAM fournit un verrouillage au niveau de la table et une 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 possède des fonctionnalités de validation, d'annulation et de récupération sur incident. INNODB prend en charge l'intégrité référentielle de clé étrangère.

Inclut les modifications de MySQL 5.6

MOTEUR DE STOCKAGE INNODB:

• Il fournit une conformité totale ACID (atomicité, cohérence, isolation, durabilité). Le multi-versioning est utilisé pour isoler les transactions les unes des autres.
• InnoDB fournit une récupération automatique après une panne du serveur MySQL ou de l'hôte sur lequel le serveur est exécuté.
• 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 plate-forme d'InnoDB entièrement intégrée en tant que moteur de stockage par défaut.
• Persistent Optimizer Stats : améliore la précision des statistiques d'index InnoDB et la cohérence des redémarrages de MySQL.
• Élagage du cache de table InnoDB: pour alléger la charge de la mémoire sur les systèmes comportant un grand nombre de tables, InnoDB libère maintenant la mémoire associée à une table ouverte. Un algorithme LRU sélectionne les tables qui ont duré le plus longtemps sans être consultées.
• Prise en charge de 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 à base de texte et les mots qu'elles contiennent. Ces index sont physiquement représentés sous forme de tables InnoDB complètes.
• InnoDB semble être bien plus rapide en recherche de texte intégral que MyISAM

Donc, il est inutile d'utiliser MyISAMEngine si vous êtes déjà passé à la version 5.6. Sinon, n'attendez pas la mise à niveau vers MySQL 5.6.

Performances InnoDB VS MyISAM utilisant MySQL 5.6

MyISAM

MyISAM est un moteur de stockage pour MySQL. Avant MySQL 5.5, c'était le moteur de stockage par défaut de 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'écriture, voire aucune. La raison pour laquelle MyISAM autorise les lectures rapides est la structure de ses index: chaque entrée pointe vers un enregistrement du fichier de données et le pointeur est décalé par rapport au début du fichier. De cette façon, les enregistrements peuvent être lus rapidement, en particulier lorsque le format est FIXED. Ainsi, les lignes sont de longueur constante. Un entrepôt de données est un domaine typique dans lequel on pourrait préférer MyISAM, car il implique des requêtes sur de très grandes tables. La mise à jour de telles tables est effectuée lorsque la base de données n'est pas utilisée (généralement de nuit). Les insertions sont également faciles car de nouvelles lignes sont ajoutées à 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, sinon 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 allonge la ligne, celle-ci est fragmentée. Pour défragmenter des lignes et réclamer de l’espace vide, laOPTIMIZE TABLELa commande doit être exécutée. En raison de ce mécanisme simple, les statistiques d'index MyISAM sont généralement assez précises. L’absence de prise en charge des transactions et de clés étrangères est un autre inconvénient majeur de MyISAM.

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 standard compatibles ACID, ainsi que la prise en charge des clés étrangères (intégrité du référentiel déclaratif). Il implémente à la fois les transactions SQL et XA, les espaces de tables, les FULLTEXTindex et les opérations spatiales selon le standard OpenGIS. Il est inclus en standard dans la plupart des fichiers 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 publique générale GNU, mais peut également être concédé aux parties souhaitant associer InnoDB à un logiciel propriétaire.

Fourches

MariaDB possède un moteur de stockage appelé Aria, décrit comme une "alternative à MyISAM sans risque d'accident". MariaDB et Percona Server utilisent par défaut une branche d'InnoDB appelée XtraDB. XtraDB est maintenu par Percona. Les modifications apportées à Oracle InnoDB sont régulièrement importées dans XtraDB. Des correctifs de bogues et des fonctionnalités supplémentaires sont ajoutés.