Établir une référence de performance

Une requête peut sembler rapide sur quelques dizaines de lignes et devenir coûteuse lorsque l’historique de la médiathèque grandit. Si vous ajoutez ou modifiez un index sans mesure initiale, vous ne pourrez pas savoir si le changement a réellement amélioré les accès attendus. Vous allez donc définir une référence avant d’optimiser.

Le modèle et les types des tables adherents, oeuvres, exemplaires, emprunts et retards sont définis dans les leçons précédentes. Ici, vous ne changez pas ce schéma : vous observez le comportement de requêtes représentatives sur des données suffisamment proches de l’usage réel.

Choisir un jeu de données représentatif

Une mesure n’a de sens que si les données reproduisent les caractéristiques qui influencent la requête : le nombre d’emprunts, leur répartition entre adhérents, ainsi que les dates présentes dans l’historique. Quelques lignes fabriquées à la main conviennent pour valider la syntaxe, mais elles ne permettent pas de tirer une conclusion sur la tenue en charge. Le projet prévoit un jeu reproductible dans sql/donnees.sql ; exécutez le même chargement pour chaque série de comparaison.

Définir des requêtes à comparer

Prenez des opérations qui correspondent à des usages concrets plutôt que des requêtes arbitraires. Par exemple, un employé peut consulter les emprunts d’un adhérent ou compter les prêts enregistrés pendant une période. Les deux requêtes ci-dessous utilisent les colonnes adherent_id et date_emprunt du projet ; elles fournissent une base simple que vous pourrez chronométrer avant et après les choix d’index.

-- Q1 : consulter les emprunts d’un adhérent.
SELECT adherent_id, date_emprunt
FROM emprunts
WHERE adherent_id = 42
ORDER BY date_emprunt;

-- Q2 : compter les emprunts créés pendant une période.
SELECT COUNT(*) AS nombre_emprunts
FROM emprunts
WHERE date_emprunt >= '2025-01-01'
  AND date_emprunt < '2025-02-01';

Q1 retourne les dates d’emprunt de l’adhérent 42, dans l’ordre chronologique. Q2 retourne une ligne contenant le nombre d’emprunts de janvier 2025 ; le résultat dépend des données chargées.

Conservez ces requêtes dans sql/requetes.sql et notez les valeurs de test choisies. L’adhérent 42 ou la période de janvier 2025 ne sont pas des valeurs universelles : vérifiez qu’elles correspondent aux données de votre jeu, puis gardez les mêmes paramètres au fil des essais. Dans le projet, les requêtes de référence restent distinctes des variantes optimisées, afin de préserver un point de comparaison lisible.

Répéter et consigner les mesures

Le temps observé peut varier d’une exécution à l’autre : le serveur peut être occupé et les données peuvent déjà être présentes dans la mémoire. Une seule durée ne suffit donc pas pour caractériser une requête. Exécutez chaque requête plusieurs fois dans les mêmes conditions et consignez les observations, en distinguant les premiers essais des suivants si leurs durées diffèrent nettement.

-- Dans le client interactif mariadb, activer le profilage de la session.
SET profiling = 1;

-- Exécuter plusieurs fois les requêtes de référence.
SELECT adherent_id, date_emprunt
FROM emprunts
WHERE adherent_id = 42
ORDER BY date_emprunt;

SELECT adherent_id, date_emprunt
FROM emprunts
WHERE adherent_id = 42
ORDER BY date_emprunt;

-- Consulter les durées relevées pour cette session.
SHOW PROFILES;

SHOW PROFILES présente les requêtes exécutées dans la session et leur durée observée, lorsque le profilage est disponible et activé dans votre serveur MariaDB.

Le profilage peut être désactivé ou indisponible selon la configuration du serveur. Dans ce cas, mesurez les requêtes avec l’outil d’exécution que vous utilisez habituellement et consignez sa méthode : ne mélangez pas des durées obtenues avec des outils ou des conditions différentes. Enregistrez au minimum la requête, ses paramètres, le nombre de lignes du jeu de test, la durée observée et l’état du schéma.

Intégrer le coût des écritures

Une mesure de lecture ne décrit pas à elle seule l’effet d’un index. Lorsqu’un emprunt est ajouté ou qu’une ligne est modifiée, MariaDB doit aussi maintenir les structures d’index concernées ; cela peut augmenter le travail et le temps nécessaires aux écritures. Vous évaluerez donc les choix futurs au regard des lectures qu’ils accélèrent et des écritures qu’ils alourdissent, sans ajouter ici de nouvel index.

• Mesurez avant de modifier le schéma : une référence est nécessaire pour juger un gain.
• Utilisez un jeu de données reproductible, assez représentatif des volumes et des usages visés.
• Gardez les mêmes requêtes, paramètres et conditions, et répétez les essais.
• Consignez les durées avec le volume testé, l’outil de mesure et l’état du schéma.
• Évaluez les gains de lecture en tenant compte du travail supplémentaire que les index imposent aux écritures.

Dans la prochaine leçon, vous choisirez des index pour les filtres et les jointures, puis vous les vérifierez sur les accès réellement utilisés par le projet.