Base de données lente? Cinq causes à vérifier avant de réécrire

Quand une application commence à peiner en période de pointe — fin de mois, grosse campagne, rush du matin —, les premières propositions sont généralement un plus gros serveur ou une réécriture. Parfois, l’une d’elles est la bonne. Bien plus souvent, la cause est l’un de cinq problèmes ordinaires, tous corrigeables sans tout recommencer.

Mesurez d’abord. Activez le journal des requêtes lentes, ou utilisez les statistiques intégrées (pg_stat_statements de PostgreSQL est un choix courant), et classez les requêtes selon le temps total consommé. Le pire coupable est rarement celui qu’on soupçonne.

1. Un index manquant ou inadéquat

De loin la cause la plus fréquente. Une requête qui filtre ou trie sur une colonne sans index approprié doit parcourir toute la table. Sur mille lignes, personne ne le remarque. Sur quelques millions, c’est tout le problème.

L’indice : une requête domine le journal, et son plan d’exécution montre un balayage complet de la table.

2. Les requêtes N+1

La page charge cinquante enregistrements, puis lance une requête distincte pour chacun afin d’obtenir les données liées — cinquante et une requêtes là où deux suffiraient. Invisible en développement avec dix enregistrements, paralysant en production avec dix mille.

L’indice : des centaines de requêtes presque identiques, rapides individuellement, par chargement de page.

3. Des jeux de résultats non bornés

Une requête sans limite qui retourne chaque ligne correspondante. Correcte quand la table était petite; lente et gourmande en mémoire une fois qu’elle grossit.

L’indice : une requête dont la durée augmente régulièrement au fil des mois sans changement de code.

4. Un pool de connexions épuisé

Chaque requête attend une connexion libre à la base. La base elle-même travaille à peine — c’est l’application qui fait la file pour lui parler.

L’indice : faible utilisation du processeur de la base, mais temps de réponse élevés et erreurs d’expiration sous charge.

5. Aucun cache là où il s’impose

La même requête coûteuse s’exécute des milliers de fois par minute et renvoie chaque fois la même réponse — un catalogue, une table de paramètres, un total de tableau de bord.

L’indice : des requêtes identiques, aux résultats identiques, à très haute fréquence.

Pourquoi cet ordre compte

Les cinq se corrigent sur place, généralement en jours ou en semaines, avec peu de risque et un retour arrière facile. Une réécriture prend habituellement bien plus de temps que prévu, et pendant ce temps vous maintenez deux systèmes sans rien livrer de nouveau.

Une réécriture est parfois réellement la bonne réponse — quand l’architecture ne peut pas supporter un besoin nouveau de l’entreprise. Mais cette conclusion doit venir de la mesure, pas la remplacer.

Nous décrivons un cas typique dans le site rame exactement quand on est le plus occupé. Le travail de performance fait partie de notre pratique en infrastructure.