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

Administration MySQL Discussion :

Migration InnoDB vers MyISAM impossible ?


Sujet :

Administration MySQL

  1. #1
    Membre expérimenté
    Avatar de yotta
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Septembre 2006
    Messages
    1 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 088
    Points : 1 540
    Points
    1 540
    Par défaut Migration InnoDB vers MyISAM impossible ?
    Bonjour,

    J'ai un soucis qui me perturbe. J'ai remarqué que l'hébergement Free de MySQL ne permet la génération de tables que dans le type MyISAM et quelques autres que sans doute personne n'utilise. Malheureusement pour moi, la base de donnée source, MySQL elle aussi mais chez moi à la maison a été créée sur le type de tables InNODB.
    J'aimerai "dupliquer" la base qui se trouve chez moi (en InnoDB) vers ma base hébergée chez Free (en MyISAM). J'ai voulu utiliser phpMyAdmin pour simplement exporter au format fichier texte SQL la base qui se trouve chez moi (en InnoDB) et ensuite l'importer dans ma base free... Et là, paf le chien. Lorsque je réalise l'opération d'importation via phpMyAdmin sur la base Free (qui ne supporte pas l'InnoDB), seule la plus petite de mes tables s'importe et est normalement transformée en type MyISAM, mais dés la seconde table, j'obtient le message d'erreur suivant :
    MySQL a repondu :

    #1071 - Specified key was too long; max key length is 1000 bytes
    Il semblerait que cela soit lié à la valeur de l'indexe, mais je n'y comprends rien. Pour précision, voici la structure de ma table InnoDB sur mon serveur personnel :

    Table : Emprunteurs (InnoDB)

    champ 'Indexe', type int(4), Non null Clé primaire auto-incrémentée
    champ 'Nom', type varchar(255) Non null chaîne vide par défaut
    champ 'Prenom', type varchar(255) Non null chaîne vide par défaut
    champ 'Service', type varchar(255) Non null chaîne vide par défaut
    champ 'Telephone', type varchar(255) null possible valeur NULL par défaut
    champ 'Email', type varchar(255) null possible valeur NULL par défaut
    Cette table contient 741 enregistrements, et la valeur de l'indexe varie entre 8 et 1156.

    Quelqu'un pourrait-il m'aider à comprendre, je ne m'en sort pas avec les explications que je trouve sur le site MySQL...

    Merci.
    Une technologie n'est récalcitrante que par ce qu'on ne la connait et/ou comprend pas, rarement par ce qu'elle est mal faite.
    Et pour cesser de subir une technologie récalcitrante, n'hésitez surtout pas à visiter les Guides/Faq du site !

    Voici une liste non exhaustive des tutoriels qui me sont le plus familiers :
    Tout sur Java, du débutant au pro : https://java.developpez.com/cours/
    Tout sur les réseaux : https://reseau.developpez.com/cours/
    Tout sur les systèmes d'exploitation : https://systeme.developpez.com/cours/
    Tout sur le matériel : https://hardware.developpez.com/cours/

  2. #2
    Rédacteur/Modérateur

    Avatar de Antoun
    Homme Profil pro
    Architecte décisionnel
    Inscrit en
    Octobre 2006
    Messages
    6 281
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : Octobre 2006
    Messages : 6 281
    Points : 11 737
    Points
    11 737
    Par défaut
    Je pense que tu confonds index et clé auto-incrémenté...

    Que te donne la requête suivante ?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    show index from Emprunteurs ;
    Antoun
    Expert Essbase, BO, SQL

    La bible d'Essbase, 2ème édition

  3. #3
    Membre expérimenté
    Avatar de yotta
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Septembre 2006
    Messages
    1 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 088
    Points : 1 540
    Points
    1 540
    Par défaut Voilà les précisions demandées
    Voilà le résultat de la requete que vous m'avez proposé :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    emprunteurs 0 PRIMARY 1 Indexe A 741 NULL NULL   BTREE   
    emprunteurs 1 Nom 1 Nom A 741 NULL NULL   BTREE
    Je n'y pércise pas les noms des colonnes. En fait, je ne sais pas comment copier/coller le résultat affiché dans phpMyAdmin pour vous le présenter tel qu'il apparaît. Je ne copie/colle que les lignes contenues dans le tableau.
    Mais je penses que vous connaissez la nature de chacun de ces champs, sinon voici les noms de colonnes dans l'ordre :

    Table, Non_unique, Key_name, Seq_in_index, Column_name, Collation, Cardinality, Sub_part, Packed, Null, Index_type

    Je crois avoir compris. Cela vient du fait que mon champ Nom, un champ de type VARCHAR définit sur une longueur de 255 caractères avec une internationalisation fixée en UTF8, a été définit en tant qu'indexe. D'après ce que j'ai compris des explications trouvées sur le site de MySQL, l'encodage UTF8 necéssite trois octets par caractères. Bref, j'ai fait un petit test qui me permet d'éviter l'erreur lorsque j'importe mon fichier sql en précédant son exportation depuis la base source d'une modification de l'encodage de mes tables en Latin1 par exemple. Maintenant, je vais voir si l'import échoue toujours sans toucher à l'encodage, mais en supprimant l'indexe associé au champ VARCHAR.

    Je vous tiens au courant...
    Une technologie n'est récalcitrante que par ce qu'on ne la connait et/ou comprend pas, rarement par ce qu'elle est mal faite.
    Et pour cesser de subir une technologie récalcitrante, n'hésitez surtout pas à visiter les Guides/Faq du site !

    Voici une liste non exhaustive des tutoriels qui me sont le plus familiers :
    Tout sur Java, du débutant au pro : https://java.developpez.com/cours/
    Tout sur les réseaux : https://reseau.developpez.com/cours/
    Tout sur les systèmes d'exploitation : https://systeme.developpez.com/cours/
    Tout sur le matériel : https://hardware.developpez.com/cours/

  4. #4
    Membre expérimenté
    Avatar de yotta
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Septembre 2006
    Messages
    1 088
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France, Bas Rhin (Alsace)

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2006
    Messages : 1 088
    Points : 1 540
    Points
    1 540
    Par défaut Cela se précise
    J'ai refait un test. Je pars de ma base source, celle qui travaille avec des tables de type InnoDB. Avant d'exporter cette table, je supprime l'indexes que j'avais positionné sur le champ Nom, puis j'exporte la table dans un fichier sql nommé emprunteurs.sql. Ensuite, je me connecte sur ma console phpmyadmin chez Free pour accéder à la base de données hébergée chez eux dans laquelle je veux importer emprunteurs.sql. Je précise que dans ce cas, sur le serveur MySQL de free, InnoDB n'est pas supporté, donc les tables sont importées en MyISAM. Et bien, sans l'indexe aucuns problèmes. Je peux importer mon fichier, tout en conservant l'encodage UTF8 avec une longueur de 255 caractères sur le champ Nom de cette table. Le plus commique, c'est qu'une fois la table importée, au format MyISAM donc, je peux remettre en place ces indexes sans problèmes. Je les avais éffectivement ajouté dans le but d'optimiser les temps de réponses pour des requetes SQL de regrouppement.
    Je penses que l'usage du format SQL pour le fichier emprunteurs.sql généré lors de l'exportation n'est pas le plus pertinent dans ce cas. Je n'ai malheureusement plus le temps de voir si ça fonctionnerai directement en choisissant un autre format.
    Merci en tout cas, Antoun, de vous être penché sur mon problème.
    Une technologie n'est récalcitrante que par ce qu'on ne la connait et/ou comprend pas, rarement par ce qu'elle est mal faite.
    Et pour cesser de subir une technologie récalcitrante, n'hésitez surtout pas à visiter les Guides/Faq du site !

    Voici une liste non exhaustive des tutoriels qui me sont le plus familiers :
    Tout sur Java, du débutant au pro : https://java.developpez.com/cours/
    Tout sur les réseaux : https://reseau.developpez.com/cours/
    Tout sur les systèmes d'exploitation : https://systeme.developpez.com/cours/
    Tout sur le matériel : https://hardware.developpez.com/cours/

  5. #5
    Membre à l'essai
    Inscrit en
    Octobre 2008
    Messages
    18
    Détails du profil
    Informations forums :
    Inscription : Octobre 2008
    Messages : 18
    Points : 12
    Points
    12
    Par défaut
    Bonjour
    j'ai le même souci si vous avez une solution

    cordialement

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 1
    Dernier message: 07/10/2013, 10h09
  2. Migration access vers sqlserver
    Par bifus dans le forum Bases de données
    Réponses: 3
    Dernier message: 24/02/2005, 07h58
  3. [Migration]java vers C
    Par chelguera dans le forum Général Java
    Réponses: 1
    Dernier message: 14/01/2005, 19h09
  4. Migration HyperFile vers SQL SERVER
    Par mathll65 dans le forum MS SQL Server
    Réponses: 3
    Dernier message: 23/03/2004, 09h57

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