Index et requêtes lentes

Pourquoi une requête devient lente

Sans index, rechercher une ligne dans une table de 10 millions d'enregistrements oblige la base à parcourir chaque ligne une par une (full table scan) jusqu'à trouver la correspondance ou atteindre la fin. Sur une table volumineuse, cela devient rapidement inacceptable.

L'index : comme le sommaire d'un livre

Un index est une structure de données auxiliaire qui permet de retrouver rapidement des lignes selon une colonne précise, sans parcourir toute la table, exactement comme le sommaire d'un livre évite de tout lire pour trouver un chapitre.

CREATE INDEX idx_clients_email ON clients(email);

Une fois cet index créé, WHERE email = 'client@exemple.com' devient quasi instantané même sur des millions de lignes, au lieu d'un parcours complet.

Le compromis : lecture rapide, écriture ralentie

Un index accélère les lectures (SELECT) mais ralentit légèrement les écritures (INSERT, UPDATE, DELETE), car l'index doit être mis à jour à chaque modification. Indexer toutes les colonnes "au cas où" dégrade les performances d'écriture sans bénéfice proportionnel.

EXPLAIN : comprendre pourquoi une requête est lente

EXPLAIN SELECT * FROM clients WHERE email = 'client@exemple.com';

EXPLAIN affiche le plan d'exécution choisi par la base : s'il indique un "full table scan" là où un index existe, quelque chose empêche son utilisation (mauvais type de comparaison, fonction appliquée sur la colonne indexée, etc.).

Cas concret

Une application ralentit progressivement à mesure que sa table de logs grossit, atteignant plusieurs millions de lignes après un an d'utilisation. La requête de recherche par date, exécutée des milliers de fois par jour, effectue un full table scan à chaque appel faute d'index sur la colonne date. Ajouter CREATE INDEX idx_logs_date ON logs(date) fait passer le temps de réponse de plusieurs secondes à quelques millisecondes.

Erreurs fréquentes

• Ne créer aucun index sur les colonnes fréquemment filtrées (WHERE) ou jointes (JOIN), laissant la base scanner intégralement la table à chaque requête.
• Sur-indexer une table : chaque index supplémentaire ralentit les écritures, un compromis à évaluer plutôt qu'à appliquer systématiquement partout.
• Ne jamais utiliser EXPLAIN pour diagnostiquer une requête lente, devinant la cause au lieu de la vérifier avec l'outil prévu exactement pour ça.

À retenir

• Un index accélère les lectures sur une colonne précise, au prix d'un léger ralentissement des écritures.
• Sans index adapté, une recherche sur une grosse table effectue un parcours complet (full table scan), lent et coûteux.
• EXPLAIN révèle le plan d'exécution réel d'une requête, la première étape pour diagnostiquer une lenteur.

Mini-exercice

Une requête WHERE date_creation = '2026-01-15' met plusieurs secondes à s'exécuter sur une table de plusieurs millions de lignes sans index sur cette colonne. Quelle commande créer, et quel effet attendre ?

Réponse : CREATE INDEX idx_table_date_creation ON table(date_creation);. Effet attendu : la requête passe d'un parcours complet de la table (lent) à une recherche directe via l'index (quasi instantanée), au prix d'un léger surcoût sur les futures écritures dans cette table.