Un gros import par une interface web échoue presque toujours : la limite d'envoi, le temps d'exécution ou le délai de la requête l'arrête en chemin. Importez en ligne de commande et rien de tout cela ne s'applique.

mysql -u user -p dbname < dump.sql
# or, compressed
zcat dump.sql.gz | mysql -u user -p dbname

Rendez-le rapide

# at the top of the session
SET autocommit=0;
SET unique_checks=0;
SET foreign_key_checks=0;
-- import --
SET foreign_key_checks=1;
SET unique_checks=1;
COMMIT;

L'essentiel du temps d'un gros import passe à vérifier les contraintes et à écrire après chaque ligne. Désactiver cela pour un dump de confiance, puis le réactiver ensuite, transforme couramment des heures en minutes.

Uniquement sur un dump auquel vous vous fiez et sur une base dans laquelle rien d'autre n'écrit. Les vérifications de clés étrangères désactivées, un dump cassé importe des données cassées en silence.

Regardez-le avancer

pv dump.sql | mysql -u user -p dbname

pv affiche une barre de progression et une estimation. Sans elle, un import long ne se distingue pas d'un import bloqué, et on le tue à mi-parcours — ce qui est pire que d'attendre.

S'il échoue en chemin

  • Disque plein — la base a besoin de place pour les données ET pour les fichiers temporaires. Vérifiez df -h avant de commencer.
  • MySQL server has gone away — une seule ligne dépasse max_allowed_packet. Augmentez-le : max_allowed_packet = 256M.
  • Unknown collation — le dump vient d'un MySQL plus récent. Soit vous mettez à niveau, soit vous réécrivez la collation dans le fichier.
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' dump.sql
Importez dans une base vide, pas par-dessus une base en production. S'il échoue à mi-chemin, vous avez une copie à moitié importée à jeter, et non un site à moitié détruit.