IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MySQL Discussion :

Changement d'engine MyISAM -> InnoDB


Sujet :

MySQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éclairé
    Inscrit en
    Janvier 2005
    Messages
    491
    Détails du profil
    Informations forums :
    Inscription : Janvier 2005
    Messages : 491
    Par défaut Changement d'engine MyISAM -> InnoDB
    Hello,
    (je précise que je ne suis pas très expérimenté en base de donnée )

    Je reprend une application existante basée sur une structure de base de donnée dont les tables sont gérées à l'aide du moteur MyISAM.

    Dans cette structure, il y a une table A qui contient des enregistrement uniques. Chaque enregistrement à un ID (la clé primaire de la table, A.id), et il y a tout une autre série de tables qui font référence à cet ID, mais indrectement car il n'y a pas de contrainte de clé étrangère.

    Autrement dit, si on prend par exemple la table B dont la clé primaire est B.id, eh bien B.id correspond en fait a A.id, et lors d'un insert dans B, on indique donc cette valeur directement (pas d'auto_increment).

    Bon le problème est que d'une part, j'ai l'impression que l'utilisation des clé étrangère est plus naturelle, et d'autre part, la supression d'une entrée dans A nécessite de supprimer les entrées dans B (et autres...) y faisant référence, et comment MyISAM ne sait pas faire (à ma connaissance), il faut gérer ca soi même.

    Le problème étant posé, je me demande si je ne vais pas passer au moteur InnoDB qui notamment autorise la gestion de clé étrangère.

    Mes questions sont donc multiples:
    - Ce passage vous semble t-il naturel dans mon cas?
    - Quels sont en pratique les inconvéniants de InnoDB par rapport à MyISAM? Sachant que mon application doit être en mesure de gérér plusieurs millions d'entrées. J'ai pu lire sur le site de MySQL que InnoDB était plus lent... Mais a quel point? Pour quel type de traitement? Enfin bref toute info est la bienvenue.
    - Etant donné une BD existante, il faudrait alterer chaque table, changer le moteur, et introduire les contraintes de clé étrangères. Cela peut-il poser un problème particulier?

    Merci d'avance de vos réponse et désolé si mes questions sont naïves.

  2. #2
    Membre Expert
    Avatar de Sivrît
    Profil pro
    Inscrit en
    Février 2006
    Messages
    953
    Détails du profil
    Informations personnelles :
    Âge : 44
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Février 2006
    Messages : 953
    Par défaut
    Citation Envoyé par vinzzzz Voir le message
    - Ce passage vous semble t-il naturel dans mon cas?
    Ça se tient. On peut vivre sans clefs étrangères, mais avoir des garanties sur l'intégrité n'est pas un mauvaise chose et justifie le (léger) impact que cela a sur les performances.



    Citation Envoyé par vinzzzz Voir le message
    - Quels sont en pratique les inconvéniants de InnoDB par rapport à MyISAM? Sachant que mon application doit être en mesure de gérér plusieurs millions d'entrées. J'ai pu lire sur le site de MySQL que InnoDB était plus lent... Mais a quel point? Pour quel type de traitement? Enfin bref toute info est la bienvenue.
    InnoDB est "réputé" plus lent, mais la question est complexe. En pratique beaucoup de choses influent (matériel, données, requêtes, charge, etc.) et il y a des cas où InnoDB sera plus performants. Notamment, pour des tables sur lesquelles les modifications (UPDATE, pas INSERT) sont fréquentes, le verrouillage plus fin d'InnoDB permet un bien meilleure concurrence.

    Le principal défaut d'InnoDB serait peut-être qu'il prend vraiment plus de place sur le disque. Mais pour "seulement" quelques millions d'entrées ça ne devrait pas poser de problème aux machines actuelles.

    Disons qu'il est "suffisamment" performant, et que le choix devrait plus se faire sur d'autres critères : besoin de transactions, de clefs étrangères... On peut aussi noter qu'InnoDB est bien plus résistant au crash et que la récupération est incomparablement plus courte (façon NTFS versus FAT et son checkdisk).

    Citation Envoyé par vinzzzz Voir le message
    - Etant donné une BD existante, il faudrait alterer chaque table, changer le moteur, et introduire les contraintes de clé étrangères. Cela peut-il poser un problème particulier?
    Le principal problème de mon point de vue est que ça peut prendre du temps, et une table est verrouillée pendant sa conversion. Il faut voir dans quelle mesure le service peut être interrompu. Si c'est un problème, la réplication permet éventuellement de faire la conversion sur un esclave avant de basculer.

    Ensuite, le problème sera plutôt la gestion des transactions par l'application. Si c'était du MyIsam, il n'y en a probablement pas. L'autocommit permet d'obtenir le même comportement, mais c'est dommage, et très dommageable pour les performances.

Discussions similaires

  1. Intérêt Engine MyIsam / InnoDB ?
    Par Ojiuiookojbezib dans le forum Langage
    Réponses: 6
    Dernier message: 24/12/2014, 09h11
  2. [dump SQL] syntax error near 'ENGINE=MyISAM
    Par pierrot10 dans le forum SQL Procédural
    Réponses: 2
    Dernier message: 27/09/2006, 12h33
  3. De MyIsam vers InnoDB
    Par cocomsa dans le forum Administration
    Réponses: 2
    Dernier message: 03/08/2006, 13h12
  4. [Débutante] Stockage images et vidéos : MyISAM ou InnoDB
    Par ultracoxy dans le forum SQL Procédural
    Réponses: 5
    Dernier message: 19/06/2006, 15h18
  5. MyIsam ou InnoDB?
    Par Julien.alkaza dans le forum Requêtes
    Réponses: 4
    Dernier message: 01/01/2006, 18h18

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo