Votre application était rapide. Le code n'a pas changé, les données si.

Rien n’a changé dans le code, et pourtant la liste met huit secondes à s’afficher. Le responsable n’est pas le code : c’est le volume, qui a franchi le seuil où l’absence d’index devient visible.

Le mécanisme

Sans index, retrouver les lignes correspondant à un critère impose de parcourir la table entière. Sur mille lignes, c’est instantané. Sur deux millions, cela se compte en secondes.

La dégradation est donc progressive et proportionnelle. Elle ne déclenche aucune alerte, parce qu’aucun seuil n’est franchi d’un coup. Elle devient simplement insupportable un jour donné.

Les colonnes qui méritent un index

Trois familles, dans l’ordre d’importance :

• celles qui servent à filtrer régulièrement — statut, date, identifiant de client ;
• celles qui portent une relation vers une autre table ;
• celles qui servent à trier les listes affichées.

L’index a un coût : il occupe de l’espace et ralentit légèrement les écritures. Indexer tout est donc aussi une erreur, plus rare que la précédente.

Le second coupable : les requêtes en cascade

Un écran affiche cinquante lignes. Pour chacune, le code va chercher le nom du client. Une requête pour la liste, cinquante pour les noms : cinquante et une allers-retours là où deux suffiraient.

C’est invisible en développement, avec trois enregistrements de test. C’est le premier problème de performance en production, et il ne se voit pas dans le code — il se voit dans le nombre de requêtes par affichage.

Compter les requêtes d’une page est le diagnostic le plus rentable qui soit. Au-delà de la dizaine pour un affichage simple, il y a une cascade.

Diagnostiquer sans outil spécialisé

Toutes les bases relationnelles savent expliquer le plan d’exécution d’une requête. La ligne à chercher indique un parcours complet de table là où un index était attendu.

Deuxième source, gratuite : le journal des requêtes lentes. L’activer avec un seuil à une seconde pendant une semaine donne la liste exacte des requêtes à traiter, classées par fréquence — et cette liste est presque toujours plus courte que redouté.

L’archivage, envisagé trop tard

Une table de journalisation qui grossit indéfiniment finit par peser sur des requêtes qui ne la concernent pas, via les sauvegardes et l’occupation mémoire.

Décider dès la conception combien de temps chaque donnée reste en ligne, et où elle va ensuite, évite d’y penser en urgence. C’est aussi ce que le règlement sur les données personnelles demande, pour d’autres raisons.