Parcours séquentiels ou parcours d’index
Sachez quand un parcours séquentiel convient, quand un parcours d’index est nécessaire et comment le planificateur prend sa décision.
Parcours séquentiels ou parcours d’index est une leçon SQL Academy gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage SQL Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Academy comprend 4 leçons au total.
Deux façons de trouver des lignes
La base de données dispose de deux stratégies fondamentales pour lire les lignes :
- Analyse séquentielle — lit chaque page de la table
- Analyse d’index — parcourt un index et récupère les lignes correspondantes
Quand l’analyse séquentielle est adaptée
Si vous avez de toute façon besoin de la majeure partie de la table, l’analyse séquentielle coûte moins cher que la lecture de l’index AND la récupération de chaque ligne correspondante. Environ : au-delà de 10 à 20 % des lignes → l’analyse séquentielle l’emporte.
Quand l’analyse d’index l’emporte
Pour les requêtes sélectives (portant sur une faible proportion des lignes), l’index est avantageux :
EXPLAIN SELECT * FROM users WHERE id = 42;
-- Index Scan using users_pkey (cost=0.43..8.45 rows=1)
EXPLAIN SELECT * FROM users WHERE active;
-- Seq Scan on users (cost=0.00..15000.00 rows=950000)
-- (because most users are active)Analyse d’index ou analyse par index seul
Parfois, l’index contient à lui seul toutes les colonnes nécessaires : il n’est pas nécessaire d’accéder à la table. C’est une analyse par index seul :
CREATE INDEX users_email_id_idx ON users(id) INCLUDE (email);
EXPLAIN SELECT email FROM users WHERE id = 42;
-- Index Only Scan using users_email_id_idxAnalyse d’index par bitmap
Pour une sélectivité moyenne, PostgreSQL peut créer un bitmap des lignes correspondantes, puis les récupérer dans l’ordre physique — ce qui est plus rapide que des E/S aléatoires :
EXPLAIN SELECT * FROM orders WHERE status = 'pending';
-- Bitmap Heap Scan on orders
-- Recheck Cond: (status = 'pending')
-- -> Bitmap Index Scan on orders_status_idxPourquoi le planificateur choisit une analyse séquentielle
Raisons courantes :
- Aucun index sur la colonne filtrée
- L’index ne peut pas être utilisé (fonction appliquée à la colonne, clauses OR, types incompatibles)
- Le nombre de lignes attendu est trop élevé pour qu’un index soit rentable
- Les statistiques sont obsolètes et le planificateur évalue mal la sélectivité
Forcer l’utilisation d’un index (avec prudence)
Vous ne pouvez pas donner directement d’indication au planificateur de PostgreSQL. À la place :
- Exécutez ANALYZE pour actualiser les statistiques
- Ajoutez l’index approprié
- Définissez des paramètres de session :
SET enable_seqscan = off;pour le diagnostic (pas en production)
Prédicats compatibles avec un index
Pour qu’un index soit utile, la clause WHERE doit être "optimisable par index" — la colonne indexée doit être comparée directement :
-- GOOD:
WHERE created_at >= '2024-01-01'
-- BAD (function on the column):
WHERE date_trunc('day', created_at) = '2024-01-01'
-- BAD (cast):
WHERE created_at::DATE = '2024-01-01'
-- FIX: add a functional index, or rewrite with range.Ordre d’un index composé
Un index sur (a, b) aide les requêtes portant uniquement sur a et celles portant sur a AND b, mais pas celles portant uniquement sur b.
La taille de l’index compte
Un index en arbre B étroit, avec des clés fréquemment utilisées, peut rester entièrement en mémoire ; un index volumineux ne le peut pas forcément. Les index plus petits sont plus rapides.
Vérifier le plan
Après avoir ajouté un index, exécutez EXPLAIN ANALYZE pour confirmer que le planificateur l’utilise réellement. Si ce n’est pas le cas, recherchez la cause.
Récapitulatif
Le choix entre analyse séquentielle et analyse d’index dépend de la sélectivité.
- Filtre sélectif → analyse d’index
- Majeure partie de la table → analyse séquentielle
- Analyse par bitmap pour les situations intermédiaires
- Surveillez la compatibilité avec les index
Vérification rapide
Pourquoi PostgreSQL pourrait-il choisir une analyse séquentielle plutôt qu’un index existant ?
Questions Fréquemment Posées
La leçon « Parcours séquentiels ou parcours d’index » est-elle gratuite ?
Oui — le texte complet de « Parcours séquentiels ou parcours d’index » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours SQL Academy, passe à CoddyKit PRO. Le cours SQL Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Parcours séquentiels ou parcours d’index » ?
Sachez quand un parcours séquentiel convient, quand un parcours d’index est nécessaire et comment le planificateur prend sa décision. Tu pratiques SQL Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer SQL Academy ?
Aucune expérience préalable n'est requise. SQL Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.
Combien de temps prend la leçon « Parcours séquentiels ou parcours d’index » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon SQL Academy ?
Oui. Chaque leçon SQL Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Lire EXPLAIN et EXPLAIN ANALYZE
- Parcours séquentiels ou parcours d’index
- Jointure par hachage, jointure par fusion ou boucle imbriquée
- Repérer et corriger les requêtes lentes