0Pricing
SQL Interview Prep · Leçon

Index B-tree et leur utilité

Ce qu’un index stocke réellement et les opérations qu’il accélère

Index B-tree et leur utilité est une leçon SQL Interview Prep gratuite sur CoddyKit. Ceci est la leçon 1 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 Interview Prep, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Interview Prep comprend 4 leçons au total.

Pourquoi les recruteurs posent des questions sur les index

Lorsqu’un recruteur vous demande « cette requête est lente, que faites-vous ? », la réponse qu’il attend implique presque toujours un index. Les index sont le levier le plus important pour améliorer les performances en lecture. Ils permettent donc de distinguer les candidats qui ont mémorisé la syntaxe de ceux qui comprennent réellement comment une base de données trouve les lignes.

Dans cette leçon, vous allez construire un modèle mental précis de l’index en arbre B : ce qu’il stocke, les opérations qu’il accélère et la manière d’en parler comme le ferait un ingénieur expérimenté.

Le problème résolu par un index

Sans index, trouver les lignes qui correspondent à une condition oblige la base de données à lire chaque ligne de la table. Il s’agit d’un balayage séquentiel (ou balayage complet de la table). Dans une table d’un million de lignes, cela signifie vérifier un million de lignes même si une seule correspond.

Un index est une structure de données triée distincte qui permet au moteur d’accéder directement aux lignes correspondantes, tout comme l’index d’un livre permet de trouver un sujet sans lire chaque page.

-- No index: the engine reads ALL rows to find this one
SELECT * FROM users WHERE email = 'ada@example.com';

Ce qu’un arbre B stocke réellement

L’index par défaut dans PostgreSQL, MySQL, SQL Server et la plupart des moteurs est un arbre B (arbre équilibré). Il stocke les valeurs de la colonne indexée dans un ordre trié, organisées dans un arbre peu profond composé de pages.

  • Chaque nœud feuille contient les clés de l’index ainsi qu’un pointeur vers la ligne réelle de la table.
  • L’arbre reste équilibré : chaque recherche ne touche donc que quelques pages, quelle que soit la taille de la table.

Une recherche descend de la racine jusqu’à une feuille en environ log(N) étapes, au lieu de parcourir les N lignes.

Créer votre premier index

Vous créez un index en arbre B avec CREATE INDEX. Nommez-le clairement afin qu’une personne qui relit votre travail puisse voir immédiatement la table et les colonnes concernées.

Une fois cet index créé, une requête filtrant sur email peut l’utiliser pour trouver la ligne correspondante en quelques lectures de pages, au lieu d’effectuer un balayage complet.

CREATE INDEX idx_users_email ON users (email);

-- Now this lookup uses the index instead of scanning
SELECT * FROM users WHERE email = 'ada@example.com';

Opérations accélérées par un arbre B

Comme un arbre B conserve les valeurs dans un ordre trié, il accélère bien plus que les correspondances exactes. Les recruteurs apprécient que vous les énumériez précisément :

  • Égalité : WHERE email = ?
  • Intervalle : WHERE age > 30, BETWEEN, <, >=
  • Correspondance par préfixe : WHERE name LIKE 'Ada%' (mais NOT '%da')
  • ORDER BY sur la colonne indexée, ce qui évite un tri
  • MIN/MAX, puisque ces valeurs se trouvent aux extrémités de la structure triée

Exemple détaillé : requête par intervalle

Considérez une table de commandes contenant des millions de lignes. Une requête de reporting demande les commandes récentes. Avec un index sur created_at, le moteur se positionne au début de l’intervalle dans l’index trié, puis avance uniquement autant que nécessaire.

L’index transforme un balayage complet de la table en balayage sur intervalle borné, en ne lisant que la portion correspondant aux critères.

CREATE INDEX idx_orders_created_at ON orders (created_at);

SELECT order_id, total
FROM orders
WHERE created_at >= '2026-01-01'
  AND created_at <  '2026-02-01';

Les index accélèrent aussi le tri

Voici un point souvent oublié : comme l’index est déjà trié, le moteur peut renvoyer les lignes dans l’ordre de l’index et éviter une étape de tri distincte. C’est important pour ORDER BY, en particulier pour la pagination des premiers résultats.

Si vous triez selon une colonne qui possède un index correspondant, l’optimiseur peut lire l’index dans l’ordre et s’arrêter dès qu’il a obtenu suffisamment de lignes.

-- Index on created_at lets this avoid a sort and stop after 10 rows
SELECT order_id, total
FROM orders
ORDER BY created_at DESC
LIMIT 10;

Le coût caché : l’accès au tas

Un index normal en arbre B ne stocke que la colonne indexée et un pointeur vers la ligne. Après avoir trouvé les entrées correspondantes, le moteur doit donc encore accéder à la table (le tas) pour lire les autres colonnes que vous avez sélectionnées.

Ce second accès est l’accès au tas. Il est peu coûteux pour quelques lignes, mais devient cher lorsqu’une requête correspond à de nombreuses lignes. C’est l’une des raisons pour lesquelles un index à faible sélectivité est parfois ignoré. (Vous verrez plus loin comment les index couvrants résolvent ce problème.)

Confirmer que l’index est utilisé

Ne prétendez jamais qu’un index est utilisé : démontrez-le avec EXPLAIN. Lors d’un entretien, expliquer le plan à voix haute montre que vous comprenez réellement le sujet.

  • Seq Scan signifie que l’index n’a pas été utilisé (NOT).
  • Index Scan ou Index Seek signifie qu’il l’a été.

Si vous avez ajouté un index mais que vous voyez toujours un balayage séquentiel, le planificateur a jugé ce balayage moins coûteux, souvent parce que la requête correspond à une portion trop importante de la table.

EXPLAIN
SELECT * FROM users WHERE email = 'ada@example.com';
-- Look for: Index Scan using idx_users_email

Les clés primaires sont déjà indexées

Voici un piège fréquent en entretien : déclarer une contrainte PRIMARY KEY ou UNIQUE crée automatiquement un index en arbre B de soutien. Vous n’avez donc pas à ajouter, et ne devriez pas ajouter, un deuxième index sur la même colonne.

C’est pourquoi les jointures et les recherches sur les clés primaires sont déjà rapides, et pourquoi la question « dois-je indexer la colonne d’identifiant ? » est généralement un piège : c’est déjà fait pour vous.

-- This already builds a unique B-Tree index on (id)
CREATE TABLE users (
  id    BIGINT PRIMARY KEY,
  email TEXT UNIQUE
);

Comment le formuler lors de l’entretien

Rassemblez les idées en une phrase claire que le recruteur pourra approuver :

« Un index en arbre B est une structure triée et équilibrée qui permet au moteur de trouver les lignes en log(N) lectures de pages au lieu de parcourir toute la table. Il accélère les opérations d’égalité, d’intervalle, de préfixe et de ORDER BY sur les colonnes indexées, mais chaque correspondance entraîne toujours un accès au tas pour les colonnes qui ne sont pas indexées. »

Appuyez ensuite cette explication avec EXPLAIN. Cette combinaison d’un modèle et de preuves est celle qui permet de marquer des points.

Vérification rapide

Vérifiez votre modèle mental de ce qu’un index en arbre B accélère.

Récapitulatif : index en arbre B

Voici les points clés à retenir pour la prochaine leçon :

  • Un arbre B stocke les valeurs indexées dans un ordre trié, au sein d’un arbre équilibré, ce qui permet des recherches en log(N).
  • Il accélère les opérations d’égalité, d’intervalle, de préfixe (LIKE en début de chaîne), de ORDER BY et de MIN/MAX.
  • Chaque correspondance nécessite toujours un accès au tas pour les colonnes qui ne figurent pas dans l’index.
  • Entourer une colonne d’une fonction ou utiliser un caractère générique en début de chaîne désactive l’index.
  • Vérifiez toujours avec EXPLAIN ; les contraintes PRIMARY KEY et UNIQUE créent automatiquement un index.

Ensuite : comment ordonner les colonnes lorsqu’un même index en couvre plusieurs à la fois.

Questions Fréquemment Posées

La leçon « Index B-tree et leur utilité » est-elle gratuite ?

Oui — le texte complet de « Index B-tree et leur utilité » 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 Interview Prep, passe à CoddyKit PRO. Le cours SQL Interview Prep comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Index B-tree et leur utilité » ?

Ce qu’un index stocke réellement et les opérations qu’il accélère Tu pratiques SQL Interview Prep 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 Interview Prep ?

Aucune expérience préalable n'est requise. SQL Interview Prep 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 1 sur 4.

Combien de temps prend la leçon « Index B-tree et leur utilité » ?

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 Interview Prep ?

Oui. Chaque leçon SQL Interview Prep 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

  1. Index B-tree et leur utilité
  2. Ordre des colonnes d’un index composite
  3. Index couvrants et parcours par index seul
  4. Quand les index nuisent : écritures et sélectivité
← Retour à SQL Interview Prep