Comment surveiller les performances des requêtes de base de données : détecter et corriger les requêtes lentes avant qu'elles n'affectent vos utilisateurs

Une page lente est rarement une page lente. La plupart du temps, c'est une requête lente. Votre application peut être bien conçue, votre cache peut être chaud et votre frontend rapide — mais un seul index manquant ou une seule requête non optimisée peut transformer une requête de 50 millisecondes en un timeout de 5 secondes. Contrairement à un crash brutal, une requête lente apparaît rarement dans les logs d'erreur. Elle dégrade silencieusement l'expérience jusqu'au départ des utilisateurs.

Surveiller les performances des requêtes de base de données n'est pas la même chose que vérifier si votre base de données est en ligne. Les deux comptent, mais répondent à des questions différentes. Ce guide passe en revue les métriques qui révèlent les requêtes lentes, le SQL exact pour les trouver dans PostgreSQL et MySQL, et comment garder un œil dessus 24h/24.

Deux questions différentes : est-elle en ligne, et est-elle rapide ?

Le monitoring de base de données se divise en deux couches. Le monitoring de disponibilité répond à une question simple : votre application peut-elle encore atteindre la base de données, et répond-elle dans un délai raisonnable ? Le monitoring des performances de requêtes répond à une question plus difficile : quelles requêtes sont lentes, pourquoi le sont-elles, et s'aggravent-elles à mesure que les données grandissent ? Vous avez besoin des deux — une base de données peut être parfaitement joignable tandis qu'une seule requête incontrôlée met votre application à genoux.

Les métriques qui comptent vraiment

Avant de partir à la chasse aux requêtes lentes, décidez de ce que vous mesurez. Ces chiffres distinguent une base de données saine d'une base sur le point de provoquer un incident :

• Latence des requêtes — le temps d'exécution d'une requête, exprimé en p50, p95 et p99. Un p50 de 10 ms avec un p99 de 3 secondes signifie que la plupart des utilisateurs vont bien, mais que quelques-uns attendent.
• Débit (QPS) — requêtes par seconde. Un pic soudain peut révéler une nouvelle fonctionnalité ou un voisin bruyant sur une infrastructure partagée.
• Taux de requêtes lentes — la part des requêtes dépassant votre seuil (par exemple 500 ms). C'est le chiffre qui devrait vous alerter en premier.
• Saturation du pool de connexions — quand toutes les connexions sont occupées, les nouvelles requêtes attendent. Un temps d'attente élevé est souvent un symptôme de requêtes lentes, pas un manque de connexions.
• Événements de verrou et de deadlock — une seule transaction de longue durée peut bloquer tout ce qui se trouve derrière elle.

Trouver les requêtes lentes dans PostgreSQL

PostgreSQL dispose d'un outil qui fait l'essentiel du travail : l'extension pg_stat_statements. Elle enregistre des statistiques agrégées pour chaque requête exécutée, dont le temps total, le temps moyen et le nombre d'appels. Activez-la une fois et vous obtenez un classement permanent de vos requêtes les plus lentes.

• Activez l'extension : exécutez CREATE EXTENSION IF NOT EXISTS pg_stat_statements;, ajoutez-la à shared_preload_libraries, puis redémarrez le serveur.
• Classez vos requêtes les plus lentes par temps moyen : SELECT query, calls, mean_exec_time, max_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
• Zoomez sur une requête unique avec EXPLAIN ANALYZE. Elle exécute la requête et affiche le plan, pour voir si elle utilise un index ou effectue un scan complet de table.
• Surveillez les Seq Scan sur une grande table, un écart important entre les lignes estimées et réelles, et les tris coûteux — les trois causes les plus courantes de requêtes PostgreSQL lentes.

Trouver les requêtes lentes dans MySQL

MySQL tient un journal des requêtes lentes que vous pouvez activer avec quelques réglages. Il capture chaque requête qui s'exécute plus longtemps que long_query_time, ce qui en fait le moyen le plus rapide de trouver vos pires coupables sans ajouter d'outil de monitoring.

• Activez-le : SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1; puis localisez le fichier avec SHOW VARIABLES LIKE 'slow_query_log_file';
• Inspectez un plan avec EXPLAIN sur n'importe quel SELECT. Regardez la colonne type — ALL signifie un scan complet de table, généralement ce qu'il faut corriger.
• Vérifiez la couverture des index avec SHOW INDEX FROM your_table; et cherchez les index manquants ou inutilisés.
• Surveillez Threads_running et Threads_connected dans SHOW STATUS; un nombre croissant de threads actifs signifie souvent que des requêtes lentes gardent des connexions ouvertes.

Corrigez la cause racine, pas le symptôme

Trouver une requête lente n'est que la moitié du travail. Les corrections se répartissent en quelques catégories bien connues :

• Index manquant — la cause la plus courante. Un index sur vos colonnes WHERE et JOIN transforme souvent un scan complet en quelques millisecondes.
• Le problème N+1 — un ORM qui exécute une requête par ligne au lieu d'une seule pour tout l'ensemble. Cherchez de nombreuses petites requêtes presque identiques dans vos logs.
• Sur-fetching — sélectionner des colonnes que vous n'utilisez jamais ou des lignes inutiles. Limitez les résultats et sélectionnez uniquement ce que vous affichez.
• Mauvaise configuration du pool de connexions — un pool trop petit met les requêtes en file d'attente ; un pool trop grand peut submerger la base de données. Ajustez-le en fonction du trafic réel.

Sachez-le avant vos utilisateurs

Les outils au niveau des requêtes vous disent ce qui est lent à l'intérieur de la base de données. Ils ne vous disent pas si votre base de données est joignable depuis votre application, ni si une requête de health-check répond encore pendant votre sommeil. C'est là qu'intervient le monitoring externe.

isthisthing.online vous permet de créer un Monitor MySQL ou PostgreSQL qui se connecte à votre base de données selon un calendrier, exécute un check et mesure le Response Time. Si la base de données cesse de répondre ou qu'un check dépasse son Timeout, vous recevez une alerte par Email, Slack ou vos autres canaux — avant que vos utilisateurs ne voient une erreur. Combiné à une chronologie d'Incident et à une Status Page publique, vous transformez « le site est devenu lent » en un message que vous envoyez plutôt qu'en un message que vous recevez.

Une checklist pratique

• Activez le journal des requêtes lentes (PostgreSQL : pg_stat_statements ; MySQL : slow_query_log).
• Trouvez vos 10 requêtes les plus lentes et exécutez EXPLAIN ANALYZE sur chacune.
• Corrigez d'abord les index manquants et le problème N+1 — ce sont eux qui apportent les plus gros gains.
• Définissez un seuil de latence et alertez dessus, pas seulement sur les erreurs.
• Ajoutez un Monitor MySQL ou PostgreSQL dans isthisthing.online pour surveiller la disponibilité et le Response Time de l'extérieur.
• Passez en revue les métriques de requêtes après chaque déploiement et chaque changement de schéma.

Les requêtes lentes ne s'annoncent pas. Elles s'accumulent jusqu'à ce que le site paraisse lent, que la base de données sature et que vous combattiez un incident que vous auriez pu éviter. Surveillez votre base de données de l'intérieur comme de l'extérieur, et laissez isthisthing.online vous prévenir en premier.

Créez votre premier Monitor dès aujourd'hui. Ouvrez votre compte gratuit et détectez les requêtes lentes avant vos utilisateurs.