Connecter MySQL à n8n : le node MySQL, ses opérations et ses pièges

MySQL fait tourner une part énorme du web francophone sans qu'on y pense : chaque installation WordPress (donc chaque boutique WooCommerce), une grande partie des applications PHP historiques, beaucoup d'ERP et de CRM maison. Quand un besoin d'automatisation touche l'une de ces bases, deux réflexes sont possibles : chercher une API REST propre côté application, ou brancher n8n directement sur MySQL. Le node MySQL de n8n couvre exactement ce second cas — un client SQL natif, proche cousin du node Postgres que nous détaillons dans notre guide du node Postgres, mais avec sa propre syntaxe de paramètres et ses propres pièges. Ce guide couvre la connexion, les six opérations disponibles, la protection contre les injections SQL, et la frontière — importante — entre accès direct à la base et passage par l'API applicative.

Quand brancher MySQL plutôt qu'une API ou Airtable

Trois cas justifient clairement le node MySQL :

• Une base applicative qui vous appartient, sans API tierce à respecter : un CRM maison, une table de configuration, un outil interne. Ici, l'accès SQL direct est le chemin le plus court.
• Du reporting transverse sur une base existante : agrégations, jointures entre plusieurs tables, requêtes que l'interface d'administration ou l'API de l'application ne proposent pas. Un GROUP BY sur des commandes WooCommerce des trois derniers mois, par exemple, est souvent plus simple à écrire en SQL qu'à reconstituer via plusieurs appels API et un node Merge.
• Une migration ou une synchronisation ponctuelle, où lire directement les tables source est plus rapide que de passer par une couche applicative pensée pour d'autres usages.

À l'inverse, dès qu'il s'agit d'écrire dans la base d'une application qui a sa propre logique métier — créer une commande WooCommerce, modifier un statut PrestaShop, mettre à jour un article WordPress — l'API REST de l'application reste le bon chemin, pas le node MySQL. Nos guides connecter WooCommerce et connecter PrestaShop détaillent ces API : elles déclenchent les hooks internes, invalident les caches et appliquent les règles métier (recalcul de stock, envoi d'emails transactionnels) qu'une simple requête UPDATE ignore complètement. Un UPDATE direct sur la table wp_posts fonctionne, mais laisse l'application dans un état incohérent que son propre code n'a jamais anticipé.

Se connecter : credentials et environnements courants

Le credential MySQL de n8n demande les champs classiques : hôte, port (3306 par défaut), base, utilisateur, mot de passe, et un réglage SSL.

MySQL en Docker local. Si n8n et MySQL tournent dans le même docker-compose, l'hôte à renseigner n'est pas localhost (qui désignerait le conteneur n8n lui-même) mais le nom du service Docker — mysql ou db, selon votre fichier. C'est l'erreur numéro un en self-hosted, la même que pour le node Postgres.

Hébergement mutualisé ou VPS (OVH, Infomaniak, Hostinger…). La plupart des hébergeurs qui font tourner WordPress ou PrestaShop exposent MySQL sur un hôte interne, parfois accessible uniquement depuis le même réseau. Si votre instance n8n vit ailleurs (Vercel, un VPS distinct, n8n Cloud), il faut soit autoriser l'IP de n8n dans le pare-feu MySQL de l'hébergeur, soit passer par un tunnel SSH — beaucoup d'hébergeurs mutualisés n'exposent d'ailleurs MySQL qu'en local et refusent toute connexion distante, auquel cas seule l'API de l'application (ou un plugin qui en crée une) reste utilisable.

Base managée (RDS MySQL, Cloud SQL, PlanetScale…) : mêmes paramètres, SSL activé, et l'IP de n8n autorisée côté groupe de sécurité. Une erreur ETIMEDOUT ou connection refused pointe presque toujours vers ce filtrage réseau plutôt que vers un mauvais identifiant.

Les six opérations du node MySQL

Le node propose deux niveaux, comme le node Postgres :

• Select — lit des lignes avec des filtres simples, sans écrire de SQL.
• Insert — ajoute une ligne en mappant les colonnes depuis les champs entrants.
• Update — modifie des lignes existantes selon une colonne de correspondance.
• Delete — supprime des lignes filtrées.
• Insert or Update (upsert) — insère si la ligne n'existe pas, met à jour sinon, sur une colonne clé que vous désignez.
• Execute Query — un champ SQL libre pour tout ce que les opérations intégrées ne couvrent pas : jointures, agrégations, sous-requêtes, appels de procédure stockée.

La règle reste la même que pour Postgres : les opérations intégrées suffisent au CRUD ligne à ligne et évitent toute faute de frappe dans un nom de colonne ; Execute Query prend le relais dès que la logique devient relationnelle.

Query Parameters : le ? plutôt que le $1

C'est le principal écart avec le node Postgres, et la source d'erreurs la plus fréquente pour qui bascule de l'un à l'autre. Le node Postgres utilise des placeholders numérotés $1, $2… Le node MySQL utilise des points d'interrogation positionnels ?, dans l'ordre où les valeurs sont fournies :

SELECT id, total, statut
FROM wp_woocommerce_orders
WHERE statut = ? AND date_creee >= ?

avec, dans le champ Query Parameters, la liste ordonnée des valeurs correspondantes : {{ $json.statut }}, {{ $json.dateDebut }}. Comme pour Postgres, ce mécanisme sépare la requête des données transmises au serveur : une valeur qui contient une apostrophe, un point-virgule ou un fragment de SQL forgé par un tiers reste traitée comme du texte brut, jamais comme du code exécutable. C'est la contre-mesure de référence documentée depuis longtemps dans la littérature sur les injections SQL, notamment la taxonomie de Halfond, Viegas et Orso (A Classification of SQL Injection Attacks and Countermeasures, IEEE Symposium on Secure Software Engineering, 2006 — voir sur Google Scholar), qui identifie les requêtes paramétrées comme la protection la plus fiable contre cette classe d'attaque, MySQL comme Postgres.

Deux nuances propres à MySQL méritent d'être connues avant de s'y fier aveuglément :

• L'ordre compte, pas le nom. Contrairement à $1/$2 qui peuvent être réutilisés à plusieurs endroits d'une même requête, chaque ? consomme une valeur de la liste dans l'ordre d'apparition. Une requête réordonnée sans réordonner la liste de paramètres produit un résultat silencieusement faux, pas une erreur.
• Les valeurs contenant une virgule ont connu des bugs de parsing dans certaines versions du node (le champ Query Parameters attend une liste séparée par des virgules). Si une valeur métier peut légitimement contenir une virgule — une adresse, un nom d'entreprise — testez-la explicitement avant la mise en production, ou isolez-la dans un node Code qui construit la requête plus finement.

Cas d'usage concret : reporting hebdomadaire sur une base WordPress/WooCommerce

Un pipeline représentatif de l'usage « reporting transverse » évoqué plus haut :

1. Schedule Trigger, chaque lundi matin.
2. Node MySQL (Execute Query) agrège les commandes de la semaine passée directement sur les tables WooCommerce, avec une jointure que l'API REST ne permet pas en un seul appel :

SELECT DATE(o.date_created_gmt) AS jour,
       COUNT(*) AS commandes,
       SUM(o.total_amount) AS ca
FROM wp_wc_orders o
WHERE o.status = ? AND o.date_created_gmt >= ?
GROUP BY jour
ORDER BY jour

3. Node Set met en forme le résultat en tableau lisible.
4. Node Slack ou Gmail envoie la synthèse à l'équipe, sur le même principe que notre rapport Google Analytics automatisé, appliqué ici directement à la base plutôt qu'à une API d'analytics tierce.

Ce pipeline reste strictement en lecture : aucun risque d'incohérence côté WooCommerce, puisqu'aucune écriture ne passe par le node MySQL.

MySQL ou PostgreSQL pour un nouveau projet

Quand la base n'existe pas encore et que le choix est ouvert, les benchmarks académiques récents penchent nettement pour PostgreSQL sur les requêtes complexes et les gros volumes. L'étude de Salunke et Ouda, A Performance Benchmark for the PostgreSQL and MySQL Databases (Future Internet, MDPI, 2024 — DOI), mesure des écarts nets sur des requêtes de sélection à grande échelle et une dégradation plus marquée de MySQL à mesure que les tables grossissent, tandis que MySQL conserve l'avantage sur des charges d'écriture simples à concurrence modérée. Pour un projet neuf sans contrainte d'existant, notre guide du node Postgres et notre guide de connexion à Supabase restent le point de départ recommandé.

Mais dans l'immense majorité des cas où n8n se connecte à MySQL, la question ne se pose pas dans ces termes : la base MySQL est déjà là, posée par WordPress, une application PHP ou un ERP existant depuis des années. Le bon réflexe n'est alors pas de migrer la base pour satisfaire n8n, mais de s'y brancher proprement — ce que ce guide couvre.

Pièges fréquents

• Écrire directement dans la base d'une application qui a sa propre logique (WooCommerce, PrestaShop, WordPress) au lieu de passer par son API : les hooks, les caches et les règles métier sont contournés, avec des incohérences difficiles à diagnostiquer ensuite.
• Concaténer des expressions {{ }} dans le texte SQL plutôt que d'utiliser Query Parameters : le réflexe qui ouvre la porte à l'injection SQL, sur MySQL comme ailleurs.
• Utiliser localhost comme hôte en Docker : depuis le conteneur n8n, ce nom désigne le conteneur lui-même, pas celui de MySQL.
• Se fier à une valeur contenant une virgule dans Query Parameters sans l'avoir testée — un point de vigilance spécifique à MySQL, absent du node Postgres.
• Oublier que le node s'exécute par item : un Execute Query alimenté par des centaines d'items lance autant de requêtes ; agrégez en amont ou réglez Query Batching.
• Se connecter avec un utilisateur MySQL disposant de tous les droits plutôt qu'un rôle dédié, limité aux tables réellement nécessaires — la même hygiène que celle détaillée dans notre guide de sécurisation des credentials API.

En résumé

Le node MySQL de n8n reprend la logique du node Postgres — opérations intégrées pour le CRUD simple, Execute Query pour le reste — avec une différence de syntaxe à retenir (? positionnel plutôt que $1/$2) et un piège spécifique sur les virgules dans les paramètres. La vraie décision n'est pas technique mais architecturale : lecture directe légitime pour du reporting ou une base qui vous appartient, API applicative obligatoire dès qu'il s'agit d'écrire dans une base dont un WordPress, un WooCommerce ou un PrestaShop porte la logique. Pour aller plus loin sur la partie e-commerce, notre guide sur l'automatisation des commandes détaille le pipeline complet côté API — et pour un premier projet IA rentable construit sur des données déjà propres (celles que ce genre de requête MySQL permet justement d'extraire), le Pack Inbox IA (79 €) applique la même logique de tri et de priorisation à votre boîte mail.