Mis à jour le 29 mars 2026

Optimiser les performances de sa base de données MySQL en production

MySQL propulse plus de 40 % des applications web dans le monde. C’est un moteur de base de données fiable et performant, mais qui nécessite un paramétrage soigneux pour donner le meilleur de lui-même en production. Une requête mal optimisée peut prendre 30 secondes au lieu de 30 millisecondes. Un paramètre de configuration par défaut peut diviser les performances par 10. Voici les leviers d’optimisation les plus efficaces pour votre base MySQL en production.

Sommaire

Diagnostiquer les problèmes de performance

Avant d’optimiser, il faut mesurer. Le diagnostic des performances MySQL repose sur plusieurs outils intégrés qui permettent d’identifier précisément les goulots d’étranglement.

Le slow query log

Le journal des requêtes lentes est le premier outil à activer sur tout serveur MySQL en production. Il enregistre toutes les requêtes dont l’exécution dépasse un seuil configurable. Commencez avec un seuil de 1 seconde, puis affinez progressivement.

  • slow_query_log = 1 : active le journal des requêtes lentes
  • long_query_time = 1 : seuil en secondes (commencez par 1, puis descendez à 0.5 ou 0.1)
  • log_queries_not_using_indexes = 1 : enregistre aussi les requêtes qui n’utilisent pas d’index

L’outil mysqldumpslow ou pt-query-digest (Percona Toolkit) analyse le slow query log et classe les requêtes par temps cumulé, permettant d’identifier rapidement les requêtes les plus coûteuses.

EXPLAIN et EXPLAIN ANALYZE

La commande EXPLAIN précédant une requête SELECT montre le plan d’exécution choisi par MySQL : quelles tables sont parcourues, dans quel ordre, avec quels index. C’est l’outil indispensable pour comprendre pourquoi une requête est lente et comment l’optimiser.

Point clé : La valeur « type » dans le résultat d’EXPLAIN est l’indicateur le plus important. Les types « ALL » (full scan) et « index » (parcours complet d’un index) sont des signaux d’alerte. Les types « ref », « eq_ref » et « const » indiquent une utilisation efficace des index. Un seul « ALL » sur une table de 1 million de lignes peut suffire à paralyser votre serveur.

Configuration du serveur MySQL

Les paramètres par défaut de MySQL sont conçus pour fonctionner sur n’importe quelle machine, y compris la plus modeste. Sur un serveur de production, ces paramètres doivent être ajustés pour exploiter les ressources disponibles.

Les paramètres InnoDB essentiels

InnoDB est le moteur de stockage par défaut de MySQL. Son paramètre le plus impactant est innodb_buffer_pool_size, qui détermine la quantité de mémoire allouée au cache des données et des index.

  • innodb_buffer_pool_size : allouez 60 à 80 % de la RAM totale si MySQL est le seul service. Pour un serveur avec 32 Go, configurez 20 à 24 Go.
  • innodb_log_file_size : augmentez à 256 Mo ou 512 Mo pour les bases avec beaucoup d’écritures
  • innodb_flush_log_at_trx_commit : 1 pour la sécurité maximale, 2 pour un compromis performance/sécurité acceptable
  • innodb_io_capacity : ajustez selon le type de stockage (200 pour HDD, 2000+ pour SSD NVMe)

Les paramètres de connexion

Le nombre de connexions simultanées et leur gestion impactent directement les performances.

  • max_connections : augmentez au-delà du défaut (151) si nécessaire, mais chaque connexion consomme de la RAM
  • wait_timeout : réduisez à 300 secondes pour libérer les connexions inactives
  • thread_cache_size : configurez à 16 ou plus pour réutiliser les threads entre les connexions
60-80 %de la RAM à allouer au buffer pool InnoDB
100xgain possible avec un bon index
40 %des applications web utilisent MySQL

Optimisation des requêtes

L’optimisation des requêtes est le levier le plus efficace pour améliorer les performances. Une requête bien écrite peut être 100 à 1 000 fois plus rapide qu’une requête naïve.

Les anti-patterns les plus courants

  • SELECT * : ne sélectionnez que les colonnes nécessaires, surtout sur les tables larges
  • Requêtes N+1 : une requête dans une boucle exécutée N fois, remplacez par un JOIN ou un IN
  • Fonctions sur les colonnes indexées : WHERE YEAR(date_col) = 2026 empêche l’utilisation de l’index, utilisez WHERE date_col BETWEEN ‘2026-01-01’ AND ‘2026-12-31’
  • OR sur des colonnes différentes : réécrivez en UNION ALL pour permettre l’utilisation des index
  • Sous-requêtes corrélées : remplacez par des JOIN quand c’est possible

Le query cache (MySQL 5.7 et antérieur)

Le query cache a été supprimé dans MySQL 8.0 car il devenait un goulot d’étranglement sur les charges avec beaucoup d’écritures. Si vous utilisez encore MySQL 5.7, évaluez son efficacité avec la variable Qcache_hit_rate. Si le taux de hit est inférieur à 50 %, désactivez-le.

En remplacement, mettez en place un cache applicatif (Redis, Memcached) pour stocker les résultats des requêtes fréquentes et coûteuses. Ce cache, géré au niveau applicatif, est plus efficace et plus prévisible que le query cache MySQL.

Stratégie d’indexation

Les index sont le mécanisme principal d’accélération des requêtes. Un index bien placé transforme un full table scan (parcours de toutes les lignes) en une recherche directe. Mais trop d’index ralentissent les écritures et consomment de l’espace disque.

Les règles d’indexation

  • Indexez toutes les colonnes utilisées dans les clauses WHERE, JOIN et ORDER BY fréquentes
  • Créez des index composites pour les requêtes qui filtrent sur plusieurs colonnes
  • Respectez l’ordre des colonnes dans les index composites : placez les colonnes les plus sélectives en premier
  • Supprimez les index non utilisés (identifiez-les avec sys.schema_unused_indexes sur MySQL 8.0)
  • Evitez les index sur les colonnes à faible cardinalité (booléens, statuts avec 2-3 valeurs)

Les covering index

Un covering index est un index qui contient toutes les colonnes nécessaires à la requête. MySQL peut répondre directement depuis l’index sans accéder à la table (visible dans EXPLAIN par « Using index »). C’est l’optimisation la plus puissante pour les requêtes de lecture fréquentes.

Maintenance et surveillance

Une base de données MySQL en production nécessite une maintenance régulière pour maintenir ses performances dans la durée. La fragmentation des tables, les statistiques obsolètes et les logs qui grossissent sont autant de facteurs de dégradation progressive.

Les tâches de maintenance régulières

  • ANALYZE TABLE : met à jour les statistiques utilisées par l’optimiseur de requêtes (mensuel)
  • OPTIMIZE TABLE : défragmente les tables InnoDB fortement modifiées (trimestriel)
  • Rotation des logs : configurez la rotation des logs binaires et du slow query log
  • Vérification de l’espace disque : surveillez la croissance des fichiers InnoDB
  • Mise à jour MySQL : appliquez les correctifs de sécurité et de performance

Le monitoring des métriques MySQL (connexions actives, requêtes par seconde, temps de réponse moyen, ratio de cache hit) dans un outil comme Grafana ou Netdata permet de détecter les dégradations avant qu’elles n’impactent les utilisateurs.

❓
Questions fréquentes
3 questions
MySQL 8.0 apporte des améliorations significatives : optimiseur de requêtes plus intelligent, window functions, CTEs, index descendants, et de nombreuses optimisations InnoDB. Les benchmarks montrent des gains de 20 à 30 % sur les charges mixtes. De plus, MySQL 5.7 a atteint sa fin de support en octobre 2023 et ne reçoit plus de correctifs de sécurité. La migration est donc recommandée tant pour les performances que pour la sécurité.
Redis est un excellent complément mais pas un substitut à l’optimisation de MySQL. Un cache Redis masque les problèmes de performance en servant les résultats depuis la mémoire, mais il ne les résout pas. Si le cache est invalidé ou si Redis tombe, les requêtes lentes reviennent. Optimisez d’abord vos requêtes et vos index, puis ajoutez Redis pour les requêtes complexes et fréquentes dont le résultat ne change pas à chaque exécution.
Plusieurs signaux indiquent un besoin d’optimisation : temps de réponse de l’application qui se dégrade avec le temps, CPU du serveur de base de données régulièrement supérieur à 50 %, requêtes dans le slow query log, utilisateurs qui se plaignent de lenteurs. Un audit rapide consiste à activer le slow query log pendant 24h et à analyser les résultats avec pt-query-digest. Les 10 requêtes les plus coûteuses concentrent souvent 80 % du problème.

Besoin d’accompagnement ?

Odyssix optimise les performances de vos bases de données MySQL en production. Audit de performance, optimisation des requêtes, configuration du serveur, mise en place du monitoring : nous accélérons votre application.

Contactez nos experts

Services associés

Odyssix peut vous accompagner

Odyssix

Rédigé par l'équipe Odyssix

Experts IT, Cybersécurité & Digital depuis 2018

Odyssix accompagne les PME dans leur transformation numérique et la sécurisation de leur système d'information. Nos experts certifiés (CEH, OSCP, ISO 27001) partagent leur expérience terrain à travers nos articles de blog.

Besoin d'en savoir plus ?

Contactez nos experts pour une démonstration personnalisée.

Nous contacter