Un export .sql ne s'importe pas dans un autre moteur de base de données : pourquoi

Un fichier SQL exporté par mysqldump depuis MySQL et importé tel quel dans PostgreSQL ou SQL Server échoue presque toujours avec des erreurs de syntaxe, alors que SQL est un langage normalisé par l’ISO (norme ISO/IEC 9075). Le problème ne vient pas d’une corruption du fichier : chaque système de gestion de base de données ajoute ses propres extensions de syntaxe et de types de données par-dessus le standard, ce qui rend un dump généré pour l’un généralement incompatible tel quel avec un autre.

Les incompatibilités les plus fréquentes entre MySQL et PostgreSQL

• Identifiants : MySQL délimite les noms de tables et colonnes avec des guillemets obliques (`nom`), PostgreSQL attend des guillemets doubles ("nom").
• Auto-incrément : le mot-clé AUTO_INCREMENT de MySQL n’existe pas en PostgreSQL, qui utilise le type SERIAL (ou GENERATED ALWAYS AS IDENTITY en syntaxe standard depuis PostgreSQL 10).
• Clauses de moteur : ENGINE=InnoDB, propre à MySQL, n’est reconnue par aucun autre système et doit être retirée.
• Types de données : des types comme TINYINT(1) (souvent utilisé comme booléen sous MySQL) n’ont pas d’équivalent direct et doivent être adaptés (BOOLEAN sous PostgreSQL).

Chaque moteur cible impose ses propres ajustements : SQL Server, par exemple, utilise TOP là où MySQL et PostgreSQL utilisent LIMIT, une différence supplémentaire à corriger lors d’une migration vers cet écosystème.

Réduire les incompatibilités dès l’export

L’option --compatible=ansi de mysqldump rapproche la syntaxe générée du standard SQL, ce qui limite certaines incompatibilités sans toutes les éliminer. Pour une migration fiable, exporter d’abord la structure seule (--no-data) permet de corriger les instructions CREATE TABLE avant de réimporter les données séparément, plutôt que de tenter d’adapter un unique fichier mêlant schéma et données volumineuses.

Ce que le format ne peut pas garantir par nature

Le fichier SQL n’a aucune signature binaire ni indicateur de moteur d’origine intégré : rien dans le fichier lui-même ne signale qu’il a été généré pour MySQL plutôt que pour un autre système, ce qui explique pourquoi l’incompatibilité n’apparaît qu’au moment de l’import, sous forme d’erreurs de syntaxe, plutôt qu’être détectée à l’avance.