Black Friday. WordPress + WooCommerce sur un VPS. La page d'accueil charge en douze secondes — pas à cause d'un trafic viral, mais d'une table postmeta sans index et d'un disque MySQL qui swap. Parallèlement, la « sauvegarde » automatique n'a jamais été restaurée ; le dernier dump date de six jours. Les bases auraient dû être posées avant la crise, pas après le post-mortem.
MySQL sur un site dynamique n'est pas « installé par l'hébergeur, donc réglé ». C'est le cœur transactionnel de votre revenu — catalogue, commandes, comptes clients. Quatre piliers tiennent la production debout : moteur sain, comptes limités, requêtes indexées, sauvegardes prouvées.
Moteur et charset propres
Commencez par vérifier ce que votre application utilise réellement :
- InnoDB obligatoire pour les tables métier — transactions, récupération après crash, clés étrangères.
- utf8mb4 pour les emojis et l'ensemble des caractères Unicode ; pas l'ancien
utf8tronqué à trois octets. - Collation cohérente sur toutes les tables — évite les jointures implicites lentes.
Vérifiez les tables legacy :
SHOW TABLE STATUS WHERE Engine != 'InnoDB';
Convertissez MyISAM avant la prochaine coupure électrique — pas le jour où une panne corrompt une table sans journal transactionnel.
Comptes et surface d'attaque
Un seul utilisateur root dans le fichier .env de WordPress ou Laravel est une mauvaise pratique courante :
| Compte | Droits | Usage |
|---|---|---|
app_user | CRUD sur app_db uniquement | PHP, WordPress, application |
backup_user | SELECT + LOCK ou outil dump | Cron de sauvegarde |
root | ALL | Administration humaine locale, pas dans .env |
Pas d'utilisateur % accessible depuis Internet. Liez MySQL sur localhost ou réseau privé si possible — voir pare-feu VPS. Un compte application compromis ne doit pas pouvoir DROP DATABASE.
Performance avant matériel
Avant d'upgrader le serveur, mesurez :
- Slow query log activé avec seuil à 1–2 secondes ; analysez chaque semaine.
- Index sur les colonnes des clauses WHERE et JOIN — pas d'index sur toutes les colonnes.
- InnoDB buffer pool à environ 70 % de la RAM dédiée MySQL sur un VPS base de données seule.
- Query cache — obsolète sous MySQL 8 ; ne cherchez pas à le réactiver.
Sous WordPress, activez un cache objet (Redis) après avoir nettoyé le SQL — pas avant. Un cache qui masque une requête de douze secondes repousse le problème, il ne le résout pas.
Sauvegardes et restauration prouvée
Une sauvegarde jamais testée n'est pas une sauvegarde :
- mysqldump quotidien chiffré hors site + binlog si restauration point-in-time requise.
- Snapshot disque si MySQL tourne localement sur le VPS.
- Test de restauration trimestriel — voir tester une restauration.
- Documentez la version MySQL du dump versus la cible de restauration.
En mutualisé, les exports passent par le panneau ou un cron si SSH est disponible — vérifiez la taille maximale et les exclusions. Comparez les offres avec MySQL managé via l'annuaire et le comparateur si la haute disponibilité devient un enjeu.
Réplication et haute disponibilité — seulement si besoin
Un réplica en lecture seule pour le reporting : utile. Un basculement automatique : complexité d'exploitation importante — souvent MySQL managé est plus rationnel. Ne répliquez pas pour « faire professionnel » sans runbook de basculement testé.
Lors d'une refonte stack, évaluez aussi Postgres managé — la migration vaut le coup si votre équipe en profite pour repenser le schéma.
Le sommet : la base tient jusqu'au premier vrai pic
Voici ce que le développement local ne révèle pas.
Posez-les avant campagne, migration ou soldes — pas après le premier DROP accidentel.
Décider et avancer sans angle mort
Sur une journée, vous pouvez poser les fondations :
- Auditez le moteur, le charset et les comptes MySQL — convertissez MyISAM, supprimez root de
.env. - Activez le slow query log et corrigez les trois requêtes les plus lentes.
- Automatisez une sauvegarde quotidienne chiffrée et planifiez un test de restauration trimestriel.
- Isolez MySQL sur localhost ou réseau privé — fermez l'accès Internet direct.
- Comparez les hébergeurs MySQL et MySQL managé via l'annuaire si la charge ou la conformité l'exigent.
Pour le cadre général des sauvegardes, enchaînez vers stratégie de sauvegarde dès que le dump automatique est en place.
Questions fréquentes
MyISAM encore acceptable en 2026 ?
Non pour les données métier. InnoDB partout : transactions, récupération après crash, clés étrangères. Convertissez les tables legacy avant la prochaine panne — MyISAM ne journalise pas les transactions.
Un seul utilisateur MySQL root pour l'app ?
Mauvaise pratique. Créez un compte application avec droits limités (SELECT, INSERT, UPDATE, DELETE) sur une seule base ; réservez root à l'administration humaine locale ou via bastion.
Sauvegarde mysqldump ou snapshot ?
Les deux se complètent : dump logique portable plus snapshot disque rapide. Testez la restauration — un dump jamais restauré n'est pas une assurance.
Quand passer à MySQL managé ?
Dès que la haute disponibilité, la restauration point-in-time ou les mises à jour de sécurité vous dépassent — ou lors d'une refonte vers Postgres managé.
MySQL pour un site dynamique : ce n'est pas la version affichée — c'est InnoDB, comptes limités, index et restauration prouvée avant que la crise ne vous apprenne le vocabulaire.