Livrer un diagnostic reproductible

Un index peut sembler efficace dans une session et ne produire aucun gain notable dans une autre. Sans connaître les données testées, les commandes lancées et les mesures obtenues, vous ne pouvez pas justifier une décision de schéma ni permettre à un collègue de la vérifier. Cette dernière leçon rassemble ces éléments dans un diagnostic que vous pouvez rejouer sur la médiathèque.

Vous avez déjà mesuré et optimisé la recherche des emprunts en retard, puis testé un prêt sous concurrence. Ici, vous ne reprenez pas ces notions : vous rendez leurs résultats compréhensibles hors de votre session de travail. Un diagnostic utile sépare les commandes exécutées, les observations relevées et votre interprétation ; il indique aussi les conditions dans lesquelles l’essai a été effectué.

Rassembler les éléments de preuve

Commencez par décrire l’environnement : version de MariaDB, état des scripts du projet, volume et provenance des données, ainsi que les conditions de la mesure. Notez si les essais ont été conduits sur la même instance et les mêmes données, et si d’autres charges pouvaient intervenir. Ne présentez pas un temps isolé comme une propriété générale de la requête : il dépend notamment de l’environnement et de l’état du cache.

Dans sql/diagnostics.sql, conservez les commandes de vérification et leurs observations. La commande suivante identifie le serveur utilisé ; gardez sa sortie dans le compte rendu, sans remplacer la version réellement constatée par celle attendue. Vérifiez également les index présents : l’index étudié doit être décrit comme une décision vérifiée, pas comme une hypothèse.

-- Enregistrer les sorties avec le compte rendu.
SELECT VERSION();

-- Confirmer l’état des index réellement présents.
SHOW INDEX FROM emprunts;

SELECT VERSION() renvoie la version du serveur MariaDB. SHOW INDEX présente les index existants sur emprunts ; relevez notamment leurs noms et colonnes.

Pour la recherche des retards, reprenez sans la modifier la requête de référence conservée dans sql/requetes.sql, puis exécutez sa version optimisée dans les mêmes conditions. Les définitions exactes et les prédicats métier doivent rester ceux déjà validés dans ce fichier : ne substituez pas un exemple simplifié qui ne mesurerait plus le même travail. Placez devant chacune des deux requêtes la commande de mesure adaptée et archivez les sorties utiles.

Comparer sans surinterpréter

Dans sql/diagnostics.sql, consignez pour chaque variante le plan obtenu, l’index effectivement choisi s’il y en a un, les estimations et les lignes observées par l’analyse d’exécution. Ajoutez la durée mesurée, les répétitions réalisées et les conditions de chaque essai. Si l’outil ou le client n’affiche pas une durée de manière directement comparable, indiquez précisément comment vous l’avez relevée.

-- Reprendre ici la requête de référence de sql/requetes.sql.
-- Conserver ses filtres et sa projection validés.
EXPLAIN
SELECT adherent_id, date_emprunt
FROM emprunts
WHERE adherent_id = 42;

-- Exemple de mesure d’exécution ; comparer la sortie observée.
ANALYZE
SELECT adherent_id, date_emprunt
FROM emprunts
WHERE adherent_id = 42;

EXPLAIN fournit le plan estimé ; ANALYZE exécute la requête et fournit des informations observées. Cet exemple sert à vérifier une recherche par adhérent, pas à remplacer la requête métier de recherche des retards.

L’exemple autonome ci-dessus reprend une requête connue du projet afin de montrer la forme du diagnostic ; il ne permet pas, à lui seul, de conclure sur l’indexation de date_retour. Pour cette décision, documentez le plan de la recherche des retards telle qu’elle est réellement définie dans sql/requetes.sql. Expliquez si l’index observé correspond au prédicat et si les lignes estimées et mesurées concordent suffisamment pour soutenir votre interprétation.

Documenter la décision et ses limites

Dans sql/index.sql, indiquez la justification de l’index non primaire sur emprunts(date_retour) à partir de vos observations : requête visée, index présents avant l’ajout, plan constaté et résultat des mesures. Le gain éventuel concerne les lectures étudiées ; notez aussi que l’index doit être maintenu lors des écritures. Si les mesures ne montrent pas d’amélioration fiable, dites-le et réexaminez le choix plutôt que de présenter l’index comme bénéfique par principe.

Le diagnostic doit aussi rappeler le contrôle fonctionnel : les deux versions de la recherche des retards ont été comparées sur des données inchangées, conformément au travail de la leçon précédente. Résumez le résultat de cette vérification sans affirmer une équivalence testée sur des données différentes. Pour les transactions, renvoyez aux scénarios de sql/transactions.sql et consignez les identifiants d’exemplaire et d’adhérents ainsi que les observations des deux sessions ; ne déduisez pas un succès de la seule présence du script.

Terminez le compte rendu par une conclusion limitée aux essais réalisés : ce qui a changé, ce que les plans et mesures montrent, et ce qu’ils ne permettent pas d’affirmer. Des données de test ne représentent pas nécessairement toutes les distributions réelles ; les résultats peuvent différer lorsque le volume, la proportion de retards ou la charge concurrente évoluent. Indiquez les conditions qui justifieraient de répéter le diagnostic en exploitation.

À retenir

• Conservez les commandes, les sorties et les conditions qui permettent de rejouer le diagnostic.
• Comparez les mêmes requêtes sur les mêmes données et vérifiez leurs résultats avant de conclure.
• Justifiez l’index sur emprunts(date_retour) par le plan et les mesures observés, sans inventer de gain.
• Présentez séparément les observations, votre interprétation et les limites des essais.