Performance

La base de données ralentit‑elle un site ?

Sa taille compte moins qu’on ne le croit. Ce qui ralentit vraiment, comment le repérer sans être développeur, et pourquoi le nettoyage ne suffit pas toujours.

Base de données : un site qui envoie cinq requêtes vers une base surchargée, un sablier, puis une base allégée et validée

C’est un coupable commode, souvent désigné à tort. Une base volumineuse n’est pas nécessairement une base lente, et une base légère peut parfaitement étrangler un site.

Ce qui ralentit réellement

Pas le volume, mais le nombre de requêtes par page et leur qualité. Une page qui interroge la base quatre‑vingts fois pour s’afficher sera lente, même sur une base minuscule.

Le second facteur est l’absence d’index sur les colonnes interrogées. Sans index, chaque recherche parcourt la table entière. Sur mille lignes, cela ne se voit pas ; sur deux cent mille, la page s’arrête.

Une base de trois cents mégaoctets bien indexée répond plus vite qu’une base de trente mal interrogée.

Comment savoir si c’est le problème ?

Un indice simple, accessible sans outil : comparez le temps d’affichage d’une page dynamique et celui d’une page très simple, comme les mentions légales. Si l’écart est important, le travail se fait bien en base.

Le second indice est le comportement aux heures de pointe. Un site rapide à six heures du matin et poussif à dix‑huit heures désigne une contention, pas un poids de page.

Qui pose ces requêtes ?

Presque toujours les extensions, et pas celles qu’on soupçonne. Un compteur de vues qui écrit à chaque chargement, un outil de statistiques interne, un module de produits recommandés recalculé pour chaque visiteur.

Sur une boutique, les coupables classiques sont les recherches à facettes et les blocs de recommandations, qui recalculent des listes que rien ne met en cache.

Nettoyer suffit‑il ?

Le nettoyage retire ce qui ne sert plus : révisions, indésirables, données temporaires expirées. Il allège la sauvegarde et accélère l’administration, ce qui est déjà appréciable.

Il ne corrige pas une requête mal écrite. Si une page interroge la base quatre‑vingts fois, elle le fera toujours après nettoyage, simplement sur une table plus courte.

Que faire alors ?

On identifie le module responsable, on le remplace ou on met son résultat en cache. Un cache d’objets répond exactement à ce besoin : il conserve en mémoire le résultat des requêtes coûteuses, au lieu de les rejouer à chaque visite.

C’est le seul cas où j’installe un cache avant d’avoir allégé le reste : ici, il ne masque pas le symptôme, il traite la cause.

Sur le même sujet : Peut‑on accélérer un site sans le refaire ? · Quelle vitesse viser, et sur quel appareil ?

Cette question vous concerne ?

Décrivez‑moi votre situation en deux lignes. Je vous donne mon avis, sans engagement.

Réponse sous 24 h · Premier échange offert