# Exporter la base sans la casser en route

> Export SQL, limites d'import de phpMyAdmin, utf8mb4 et collations MySQL 8 face à MariaDB : déplacer la base d'un site d'un mutualisé à l'autre sans erreur.


*Ou : le fichier SQL voyage bien, c'est l'arrivée qui pose problème.*

La réponse courte : on exporte la base depuis le phpMyAdmin de l'ancien hébergeur au format SQL, on crée chez le nouveau une base vide et son utilisateur, on importe le fichier, puis on reporte le nom de la base, l'utilisateur, le mot de passe et le serveur dans le fichier de configuration du site, `wp-config.php` pour WordPress. Deux obstacles reviennent dans presque toutes les migrations. Le premier est la taille : l'import passe par PHP, dont les limites figurent en tête de la [FAQ de phpMyAdmin sur les gros fichiers](https://docs.phpmyadmin.net/en/latest/faq.html). Le second est la compatibilité entre MySQL et MariaDB, qui se joue souvent sur une seule collation. C'est l'étape où [la migration vers un nouvel hébergeur](/guides/hebergement-web/changer-hebergeur-migration/) casse le plus souvent sans prévenir.

Rien de tout cela ne demande un accès SSH. Tout se fait dans le panneau de l'hébergeur et dans phpMyAdmin, l'outil que proposent couramment les panneaux d'hébergement, et c'est pour ce cas que cette page est écrite.

## Migrer une base de données MySQL vers un autre hébergeur sans erreur d'import

Avant d'exporter, relevez deux informations sur la page d'accueil de phpMyAdmin, chez l'ancien comme chez le nouvel hébergeur : le type de serveur, MySQL ou MariaDB, et sa version. Elles disent à l'avance si l'import passera tel quel.

| Obstacle | Symptôme à l'import | Parade sans accès serveur |
|---|---|---|
| Fichier trop gros | Taille maximale dépassée, ou page blanche | Exporter en `.sql.gz`, que phpMyAdmin importe directement ; découper le fichier avec BigDump |
| Délai d'exécution | Import arrêté en cours de route | Importer en plusieurs fichiers, table par table ; demander au support un import côté serveur |
| Collation MySQL 8 inconnue | `Unknown collation: 'utf8mb4_0900_ai_ci'` | Remplacer la collation dans le fichier SQL, ou choisir un serveur MariaDB récent |
| Mauvais jeu de caractères | Accents transformés en « é » | Exporter et importer en UTF-8, sans conversion |

Les limites de taille et de durée viennent de PHP, pas de phpMyAdmin. La FAQ en cite quatre : `max_execution_time`, `upload_max_filesize`, `memory_limit` et `post_max_size`, cette dernière devant dépasser la précédente. Le délai propre à phpMyAdmin, `ExecTimeLimit`, vaut 300 secondes par défaut. Sur un mutualisé, ces valeurs se règlent parfois dans le panneau, parfois pas du tout. La [documentation d'import et d'export](https://docs.phpmyadmin.net/en/latest/import_export.html) précise que le formulaire d'envoi accepte les fichiers compressés en gzip ou bzip2, ce qui réduit fortement la taille d'un export SQL, un texte très répétitif. Au-delà, la FAQ mentionne BigDump, un script tiers qui découpe l'import, et le dossier d'envoi `UploadDir`, que seul l'hébergeur peut activer.

La collation, c'est la règle de tri et de comparaison des textes. MySQL 8 utilise par défaut le jeu `utf8mb4` et la collation `utf8mb4_0900_ai_ci`, comme l'indique la [documentation de MySQL](https://dev.mysql.com/doc/refman/8.0/en/charset-server.html). MariaDB n'accepte ces noms, comme alias de ses propres collations, que depuis sa version 11.4.5, selon le [ticket MDEV-20912](https://jira.mariadb.org/browse/MDEV-20912) de son suivi de bugs. Un export venu d'un MySQL 8 échoue donc sur un MariaDB plus ancien. La parade courante consiste à remplacer, dans le fichier SQL ouvert avec un éditeur de texte, `utf8mb4_0900_ai_ci` par `utf8mb4_unicode_ci`, que les deux serveurs connaissent, avant d'importer.

![Illustration : un entonnoir qui verse un liquide ambré dans une bouteille étroite, avec un léger débordement](/images/migrer-base-de-donnees-hebergeur-entonnoir.original.webp "Le fichier SQL passe par l'entonnoir de PHP : trop gros ou trop lent, il déborde avant d'arriver.")

Dernier piège, l'encodage. La même documentation de MySQL rappelle que l'ancien `utf8`, devenu `utf8mb3`, stocke trois octets par caractère au plus et ne peut pas enregistrer les caractères dits supplémentaires, émojis compris, que `utf8mb4` accepte. Une base ancienne en `latin1` ou en `utf8mb3` se migre sans conversion, telle quelle : c'est la conversion improvisée pendant l'import qui fabrique les « é ».

### La base de WordPress, avec ses URL dedans

Pour WordPress, la base contient aussi l'adresse du site, et parfois des milliers de liens vers ses propres images. Tant que le domaine reste le même, rien n'est à modifier. S'il change, un remplacement naïf dans le fichier SQL casse les données sérialisées des extensions. Les outils qui s'en chargent proprement, et les extensions qui déplacent base et fichiers d'un coup, sont comparés dans [les deux méthodes de migration d'un WordPress](/guides/hebergement-web/changer-hebergeur-migration/migrer-cms-extension-ou-manuel/).

### Vérifier la base avant que les visiteurs ne la voient

Un import qui se termine sans erreur ne prouve pas que le site fonctionne : un mot de passe mal reporté dans la configuration suffit à afficher une erreur de connexion. Avant de basculer le DNS, ouvrez le site chez le nouvel hébergeur, connectez-vous à l'administration, publiez puis supprimez un contenu de test. La méthode pour le voir avant tout le monde est décrite dans [le test par le fichier hosts](/guides/hebergement-web/changer-hebergeur-migration/tester-site-avant-bascule-dns/).

### Laisser l'hébergeur faire l'import

Quand la base pèse plusieurs centaines de mégaoctets, la solution la plus simple est souvent de demander au nouvel hébergeur d'importer le fichier lui-même, depuis le serveur, sans passer par les limites de PHP. Certains le font dans le cadre d'une migration offerte, avec des conditions qui varient beaucoup d'une maison à l'autre. Elles sont relevées dans [ce que recouvre une migration gratuite](/guides/hebergement-web/changer-hebergeur-migration/migration-gratuite-hebergeur/).


---

Cette page contient des liens d'affiliation. Si tu souscris via ces liens, je peux toucher une commission sans coût supplémentaire pour toi. Mon avis reste indépendant et s'appuie sur mon expérience de client de plusieurs hébergeurs, sur leur documentation officielle et sur les tarifs vérifiés à la date de rédaction.