Bon, MySQL 8.4 LTS vient de sortir et franchement, cette version apporte des améliorations qui valent le coup pour nos sites WordPress. Vous hésitez peut-être à migrer par peur de casser quelque chose (et on vous comprend !), mais avec une bonne préparation, c’est plus simple qu’on ne le pense. On va voir ensemble comment réussir cette migration et surtout comment optimiser cette nouvelle version pour booster les performances de votre WordPress.
Préparatifs et mise en contexte de la migration
Alors, vous envisagez de migrer votre site WordPress vers MySQL 8.4 ? Excellente idée ! Mais avant de se lancer tête baissée dans cette aventure (j’ai appris à mes dépens qu’il vaut mieux être préparé), faisons un tour d’horizon de la situation actuelle.
État des lieux MySQL 5.7 et 8.0
Bon, soyons francs : la situation n’est pas brillante côté versions MySQL. D’après les statistiques WordPress.org, 33,4% des sites utilisent encore MySQL 5.7… problème de taille, cette version a atteint sa fin de vie en octobre 2023. Plus de support sécuritaire, donc vos sites sont potentiellement vulnérables.
Pour MySQL 8.0, seulement 11,4% des sites ont franchi le pas. C’est dommage car cette version apporte déjà des améliorations notables : performances accrues, nouvelles fonctionnalités JSON, window functions… Mais attention, certains hébergeurs traînent encore les pieds pour la proposer.
Pourquoi passer à MySQL 8.4 LTS
Maintenant, parlons de MySQL 8.4 LTS (Long Term Support) – et là, ça devient intéressant ! Cette version bénéficie d’un support étendu jusqu’en 2032, ce qui nous donne une tranquillité d’esprit non négligeable.
Les performances sont au rendez-vous : optimisations du moteur InnoDB, amélioration des requêtes complexes, gestion mémoire plus efficace. Pour WordPress, cela se traduit par des temps de chargement réduits et une meilleure résistance aux pics de trafic. Et croyez-moi, quand votre site se retrouve en première page de Hacker News, vous appréciez ces optimisations !
Vérification de la compatibilité WordPress
Avant toute migration, direction l’outil Site Health de WordPress (Outils > Santé du site). Cette fonctionnalité native affiche des informations cruciales sur votre configuration MySQL actuelle : version, taille des bases de données, extensions actives.
Attention cependant : MySQL 8.4 désactive par défaut le plugin mysql_native_password. Résultat ? Des erreurs de connexion potentielles avec certains plugins ou thèmes qui utilisent encore cette méthode d’authentification (oui, ça m’est arrivé avec un plugin de sauvegarde). Il faudra donc vérifier cette compatibilité avant la migration ou configurer MySQL pour maintenir ce plugin temporairement.
Processus de migration étape par étape
Bon, maintenant qu’on a vérifié la compatibilité, passons aux choses sérieuses ! La migration vers MySQL 8.4, c’est comme déménager : on ne fait pas ça à la légère et on prépare tout méticuleusement. Je vais être honnête avec vous, j’ai déjà vu des migrations foireuses qui ont mis des sites hors ligne pendant des heures… Donc on va faire ça proprement !
Sauvegarde et préparation
Première règle d’or : TOUJOURS sauvegarder avant de migrer. Et quand je dis toujours, c’est TOUJOURS ! Une sauvegarde complète inclut deux éléments critiques : la base de données ET tous les fichiers WordPress.
Pour la base de données, utilisez mysqldump :
mysqldump -u root -p --single-transaction --routines --triggers nom_de_votre_base > backup_pre_migration.sql
Pour les fichiers, une simple archive tar suffit :
tar -czf wordpress_backup_$(date +%Y%m%d).tar.gz /path/to/wordpress/
Attention : vérifiez que votre espace disque est suffisant ! J’ai déjà vu des sauvegardes échouer à 90% par manque d’espace. Testez aussi la restauration de votre sauvegarde sur un environnement de test – une sauvegarde non testée, c’est comme pas de sauvegarde du tout.
Migration des authentifications utilisateurs
Voici le gros piège de MySQL 8.4 : le plugin d’authentification mysql_native_password n’est plus activé par défaut ! WordPress utilise encore ce système d’authentification, et donc votre site ne pourra plus se connecter à la base après migration.
La solution ? Migrer vos utilisateurs MySQL vers caching_sha2_password (qui est plus sécurisé d’ailleurs). Voici les commandes SQL exactes :
-- Modifier l'utilisateur WordPress existant
ALTER USER 'wordpress_user'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'votre_mot_de_passe';
-- Vérifier que le changement a été pris en compte
SELECT user, host, plugin FROM mysql.user WHERE user='wordpress_user';
-- Recharger les privilèges
FLUSH PRIVILEGES;
Si vous avez plusieurs utilisateurs WordPress (environnement multi-sites par exemple), répétez l’opération pour chacun d’eux. Cette étape est cruciale : sans ça, WordPress ne pourra tout simplement pas se connecter à MySQL 8.4.
Mise à jour du fichier wp-config.php
Bonne nouvelle : dans la plupart des cas, aucune modification n’est nécessaire dans wp-config.php ! MySQL 8.4 reste compatible avec les paramètres de connexion existants de WordPress.
Cependant, si vous rencontrez des problèmes de connexion SSL ou de charset, vous pouvez ajouter ces constantes :
// Forcer l'utilisation du charset UTF-8
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', 'utf8mb4_unicode_ci');
// Optionnel : paramètres SSL si nécessaire
define('MYSQL_SSL_CA', '/path/to/ca-cert.pem');
Personnellement, je recommande de garder wp-config.php tel quel dans un premier temps, et de ne modifier que si vous rencontrez des problèmes spécifiques. WordPress gère très bien la détection automatique des paramètres optimaux.
Tests post-migration
Une fois la migration terminée, place aux tests ! WP-CLI est votre meilleur ami pour vérifier que tout fonctionne :
# Test de connectivité basique
wp db check
# Vérification de l'intégrité de la base
wp db repair
# Test d'une requête simple
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_status='publish';"
Pour les tests de performance, Query Monitor est indispensable. Avant la migration, notez vos métriques de base : temps d’exécution des requêtes, nombre de requêtes par page, utilisation mémoire. Après migration vers MySQL 8.4, vous devriez observer une amélioration notable, surtout sur les requêtes complexes avec des JOINs.
Je recommande aussi de tester les fonctionnalités critiques de votre site : connexion utilisateur, commandes e-commerce, formulaires de contact… Bref, tout ce qui interagit avec la base de données. Et surtout, gardez votre sauvegarde sous le coude pendant au moins 48h après la migration, le temps d’être sûr que tout roule !
Optimisations spécifiques MySQL 8.4 pour WordPress
Maintenant que la migration est terminée, passons aux choses sérieuses : optimiser MySQL 8.4 pour WordPress. Et croyez-moi, il y a de quoi faire ! Les nouvelles fonctionnalités de cette version peuvent vraiment transformer les performances de votre site.
Configuration optimale du fichier my.cnf
Commençons par le nerf de la guerre : la configuration MySQL. Voici ma configuration optimisée pour WordPress avec MySQL 8.4 :
[mysqld]
# Buffer Pool (50-75% de votre RAM)
innodb_buffer_pool_size = 2G
# Nouvelles options MySQL 8.4
innodb_redo_log_capacity = 512M
innodb_log_buffer_size = 512M
# Désactiver le binlog pour de meilleures performances (si pas de réplication)
disable_log_bin = ON
# Optimisations classiques
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
query_cache_type = 0
max_connections = 200
Attention : l’innodb_buffer_pool_size doit représenter 50 à 75% de votre RAM disponible. Si vous avez 4GB, mettez 2-3GB maximum.
Optimisation des tables wp_posts et wp_options
La table wp_options, c’est souvent le cauchemar des développeurs WordPress. Première règle : maintenez les données autoload sous 800KB. Vous pouvez vérifier avec cette requête :
SELECT SUM(LENGTH(option_value)) as autoload_size
FROM wp_options
WHERE autoload = 'yes';
Pour optimiser cette table, créez cet index spécifique :
CREATE INDEX autoloadindex ON wp_options(autoload, option_name);
Concernant wp_posts, ce nouvel index composite va considérablement accélérer vos requêtes :
CREATE INDEX idx_post_type_status ON wp_posts (post_type, post_status);
Cet index est particulièrement efficace pour les requêtes WordPress qui filtrent par type de contenu et statut.
Nouveaux index et requêtes SQL optimisées
MySQL 8.4 introduit des améliorations dans l’optimiseur de requêtes. Voici quelques index supplémentaires qui font la différence :
-- Pour wp_postmeta
CREATE INDEX idx_meta_key_value ON wp_postmeta(meta_key, meta_value(20));
-- Pour wp_usermeta
CREATE INDEX idx_user_meta_key ON wp_usermeta(user_id, meta_key);
Pour identifier les requêtes problématiques, utilisez EXPLAIN avec le nouveau format JSON :
EXPLAIN FORMAT=JSON SELECT * FROM wp_posts
WHERE post_type = 'post' AND post_status = 'publish';
Le format JSON vous donne des détails précis sur l’utilisation des index et les coûts d’exécution.
Surveillance des performances avec Percona PMM
Percona PMM (Percona Monitoring and Management) est devenu incontournable pour surveiller MySQL 8.4. L’installation est simple :
# Installation du client PMM
sudo yum install pmm2-client
# ou pour Ubuntu/Debian
sudo apt install pmm2-client
# Configuration
pmm-admin config --server-insecure-tls --server-url=http://admin:admin@localhost:8080
Avec PMM, vous obtenez des métriques détaillées sur vos requêtes WordPress. Les tableaux de bord Query Analytics et MySQL Overview vous montrent exactement où sont vos goulots d’étranglement.
Bon, je dois avouer que la première fois que j’ai vu tous ces graphiques, j’étais un peu perdu. Mais concentrez-vous sur les requêtes les plus lentes et leur fréquence d’exécution. C’est là que vous gagnerez le plus de temps !