Comment corriger l’erreur MySQL 1064 ?

Erreur MySQL 1064 — message exact : You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '...' at line N

MySQL ne parvient pas à analyser le SQL que vous avez soumis. Le fragment affiché entre guillemets indique exactement l’endroit où l’analyse s’est arrêtée — commencez votre diagnostic à cet endroit.

L’erreur MySQL 1064 est une erreur de syntaxe : MySQL a reçu une instruction SQL qu’il n’a pas pu analyser. Le message d’erreur inclut toujours le numéro de ligne et le fragment de requête à l’origine de l’échec — ce sont vos indices de diagnostic les plus rapides. Causes fréquentes :

1. Syntaxe incorrecte — une faute de frappe, une virgule manquante ou un mot-clé mal placé.
2. Erreurs d’orthographe — SLECT au lieu de SELECT, WHER au lieu de WHERE.
3. Mots réservés — utiliser order, table ou key comme noms de colonnes ou de tables sans backticks.
4. Parenthèses non appariées — une ( non fermée ou une ) en trop dans une sous-requête.
5. Données manquantes ou incorrectes — une variable de la requête est vide ou contient une valeur inattendue.
6. Syntaxe obsolète — des commandes issues d’anciennes versions de MySQL (TYPE=MyISAM, CHARSET=latin1) qui échouent sur les serveurs plus récents.

De quelle cause s’agit-il ?

Utilisez ce tableau pour identifier la cause la plus probable avant de passer aux solutions :

Résoudre l’erreur MySQL 1064

1. Vérifiez deux fois votre syntaxe

Le message d’erreur de MySQL vous indique la position exacte du caractère où l’analyse s’est arrêtée. Lisez le fragment cité dans l’erreur, puis examinez le SQL situé juste avant ce point. Les problèmes structurels les plus courants :

• Virgule manquante entre les définitions de colonnes dans CREATE TABLE
• Un point-virgule à l’intérieur du corps d’une procédure stockée qui met fin prématurément à toute l’instruction
• Un mot-clé utilisé dans la mauvaise clause (WHERE au lieu de HAVING sur une requête d’agrégation)

Exemple avant/après — virgule manquante :

-- Broken: no comma after the first column definition
CREATE TABLE users (
    id INT NOT NULL
    username VARCHAR(50)
);

-- Fixed
CREATE TABLE users (
    id INT NOT NULL,
    username VARCHAR(50)
);

2. Faites attention aux parenthèses

Chaque parenthèse ouvrante doit avoir une parenthèse fermante correspondante. Les sous-requêtes et les clauses IN (...) sont la source la plus courante de déséquilibre des parenthèses — en particulier lorsque vous modifiez une requête à la main ou que vous l’assemblez à partir de fragments.

Exemple avant/après — sous-requête non fermée :

-- Broken: missing closing ) for the IN subquery
SELECT * FROM orders WHERE user_id IN (
    SELECT id FROM users WHERE active = 1
;

-- Fixed
SELECT * FROM orders WHERE user_id IN (
    SELECT id FROM users WHERE active = 1
);

3. Erreurs d’orthographe : Un coupable courant

MySQL ne tente pas de corriger automatiquement un mot-clé mal orthographié — il arrête immédiatement l’analyse et renvoie une erreur 1064. Un seul caractère interverti dans SELECT, INSERT, UPDATE, WHERE ou tout autre mot réservé suffit à la déclencher.

Exemple avant/après — SELECT mal orthographié :

-- Broken
SLECT id, name FROM users;
-- Error: ... near 'SLECT id, name FROM users'

-- Fixed
SELECT id, name FROM users;

Un robuste SQL Syntax Checker détecte ces fautes de frappe avant que vous n’exécutiez la requête sur une base de données en production.

Ici, il identifie l’erreur et précise la ligne qui contient l’erreur.

4. Échappez correctement les mots réservés

MySQL réserve certains mots pour sa propre syntaxe : ORDER, TABLE, KEY, INDEX, DATABASE, SELECT, FROM, WHERE et bien d’autres. Utiliser l’un d’eux comme nom de table ou de colonne sans backticks provoque une erreur 1064. La solution consiste à entourer l’identifiant de backticks.

Exemple avant/après — mot réservé comme nom de table :

-- Broken: ORDER is a MySQL reserved word
SELECT name FROM order WHERE id = 1;
-- Error: ... near 'order WHERE id = 1'

-- Fixed: backticks tell MySQL this is an identifier, not a keyword
SELECT name FROM `order` WHERE id = 1;

CREATE TABLE `order` (...

Les différentes versions de MySQL ont des listes de mots réservés différentes. Lors de la migration d’une base de données depuis une ancienne version de MySQL, un mot qui ne posait pas de problème dans MySQL 5.7 peut être réservé dans MySQL 8.0. Consultez le MySQL Reference Manual pour votre version cible et effectuez un rechercher-remplacer sur le dump avant l’import.

5. Aborder les données manquantes

Si une variable PHP qui alimente une requête SQL est vide ou non définie, le SQL assemblé devient incorrect. Une requête comme WHERE id = (sans rien après le =) est une concaténation de chaînes PHP valide mais un SQL invalide.

Exemple avant/après — variable vide :

// $orderId is empty — the POST field was not submitted
$orderId = $_POST['order_id'] ?? '';

// Resulting SQL is broken:
// SELECT * FROM orders WHERE id =
$sql = "SELECT * FROM orders WHERE id = $orderId";

Validez la variable avant de construire la requête :

// Fixed: validate before use
if (empty($orderId) || !is_numeric($orderId)) {
    return; // do not run a malformed query
}
$sql = "SELECT * FROM orders WHERE id = " . intval($orderId);

Pour diagnostiquer ce problème dans un environnement WordPress en production, ouvrez phpMyAdmin ou Adminer, accédez au panneau de requête SQL et exécutez la requête avec une valeur littérale connue pour être correcte afin de confirmer que la syntaxe est valide isolément. Si elle passe à cet endroit, le problème vient de la façon dont la variable est renseignée, et non de la structure de la requête elle-même.

6. Mise à niveau des commandes obsolètes

La syntaxe de MySQL change d’une version majeure à l’autre. Les dumps de base de données générés sur MySQL 5.x contiennent fréquemment une syntaxe qui échoue immédiatement sur les serveurs MySQL 8.x. Les deux causes les plus courantes lors des migrations de sites WordPress :

TYPE=MyISAM (supprimé ; utilisez ENGINE=InnoDB) :

-- Broken on MySQL 5.5+ (TYPE= keyword was removed)
CREATE TABLE wp_options (
    option_id BIGINT(20) NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (option_id)
) TYPE=MyISAM;

-- Fixed
CREATE TABLE wp_options (
    option_id BIGINT(20) NOT NULL AUTO_INCREMENT,
    PRIMARY KEY (option_id)
) ENGINE=InnoDB;

DEFAULT CHARSET=latin1 sur un MySQL 8 strict :

Les anciens dumps spécifient CHARSET=latin1. Sur MySQL 8.0 avec character_set_server=utf8mb4 et sql_mode=STRICT_TRANS_TABLES, cela peut provoquer une erreur 1064 sur la ligne CREATE TABLE. Corrigez le dump avant l’import :

-- Find in the dump file:
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

-- Replace with:
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

D’après les tickets de support WP STAGING, le déclencheur 1064 le plus fréquent lors des migrations WordPress est un ancien dump qui contient TYPE=MyISAM — il échoue sur le premier CREATE TABLE et interrompt tout l’import. Un rechercher-remplacer dans un éditeur de texte avant de lancer l’import le résout immédiatement.

Pour confirmer la version de MySQL que votre serveur exécute :

SELECT VERSION();

Consultez le MySQL Reference Manual pour une liste complète de la syntaxe supprimée et modifiée d’une version à l’autre.

Que faire si la solution ne fonctionne pas

Si vous avez passé en revue les six causes et que l’erreur 1064 persiste, utilisez cette liste de contrôle pour isoler la cause profonde :

1. Vérifiez que vous êtes connecté à la bonne base de données. Exécutez SHOW TABLES; pour confirmer que la table que vous interrogez existe et porte exactement le nom attendu par votre requête — y compris le préfixe des tables WordPress.
2. Vérifiez votre version de MySQL :Si la syntaxe de la requête nécessite une version de MySQL plus récente que celle installée, mettez à niveau MySQL ou réécrivez la requête pour la version installée.
3. Vérifiez le préfixe des tables WordPress. Les tables WordPress utilisent le préfixe défini dans wp-config.php (généralement wp_). Une requête qui code en dur wp_options échoue si le préfixe réel est wpstg_ ou un autre.
4. Isolez la clause défaillante. Réduisez la requête à sa forme la plus simple — supprimez les jointures, les sous-requêtes et les clauses WHERE une par une jusqu’à ce que l’erreur 1064 disparaisse. La dernière clause que vous avez supprimée est la cause.
5. Activez la journalisation de débogage de WordPress. Si l’erreur 1064 provient d’une extension ou d’un thème, activer WP_DEBUG et WP_DEBUG_LOG capture la requête complète avec sa trace d’appel. Consultez comment activer le mode journal de débogage de WordPress — l’entrée du journal nommera la fonction exacte qui génère la requête incorrecte.

Conclusion

L’erreur MySQL 1064 remonte toujours à une cause précise : une faute de frappe, un mot réservé utilisé sans backticks, des parenthèses non appariées, une variable manquante ou une syntaxe obsolète dans un dump de base de données. Le message d’erreur de MySQL vous donne le numéro de ligne et le fragment exact où l’analyse a échoué — c’est votre point de départ. Appliquez la solution correspondante ci-dessus, et utilisez la liste de contrôle de dépannage si la première tentative ne le résout pas.

Articles Connexes

• 3 façons de dépanner les erreurs de syntaxe dans WordPress
• Comment dépanner l’erreur 502 Bad Gateway dans WordPress
• Comment créer et ajouter un utilisateur administrateur avec MySQL dans WordPress
• Comment corriger « Another Update is Currently in Progress » dans WordPress
• 3 façons de changer le préfixe des tables de la base de données WordPress

Auteur : Rene Hermenau

À propos de l'auteur : René Hermenau est le fondateur de WP STAGING. Il travaille sur les sauvegardes WordPress, les environnements de staging, les migrations, la gestion des bases de données et les workflows de déploiement sécurisés.

Voir le profil complet de l'auteur Rene Hermenau