Introduction aux index SQL

Bonne lecture et bon apprentissage !
Junior TSAFACK – 08/08/2026
⏱️ Temps de lecture estimé : 6 minutes

En SQL, les index sont des ressources très utiles qui permettent d’accéder plus rapidement aux données. Cette page explique le fonctionnement des index et leurs intérêts pour accroître les performances de lecture des données.

Analogie pour comprendre les index en SQL

Un index, dans le domaine bibliographique, permet de lister les mots-clés importants abordés dans un ouvrage et d’indiquer les pages où le mot est mentionné. Ainsi, un lecteur qui recherche une thématique spécifique peut se baser sur cet index pour trouver les pages qui abordent le sujet. Un index est une ressource non indispensable, mais c’est un gain de temps considérable pour l’utilisateur qui accède facilement à l’information recherchée.

Index d'un livre :
--------------------
Base de données ...... 45, 78, 92, 103
SQL ................... 12, 34, 56, 78
Performance ............ 89, 101, 112, 145

Sans index, le lecteur devrait parcourir l’intégralité du livre pour trouver une information. Avec un index, il trouve immédiatement les pages pertinentes. C’est exactement le même principe dans une base de données.

Index en SQL

Un index dans une base de données se base sur le même principe qu’un index dans un livre. Avec un index placé sur une ou plusieurs colonnes, le système de gestion de base de données peut rechercher les données d’abord sur l’index. S’il trouve ce qu’il cherche, il sait plus rapidement où se trouvent les enregistrements concernés.

Fonctionnement simplifié :

Table (sans index) :
┌────┬──────────┬────────────┐
│ id │ nom      │ ville      │
├────┼──────────┼────────────┤
│ 1  │ Dupont   │ Paris      │ ← Ligne 1
│ 2  │ Martin   │ Lyon       │ ← Ligne 2
│ 3  │ Durand   │ Paris      │ ← Ligne 3
│ 4  │ Petit    │ Marseille  │ ← Ligne 4
│ 5  │ Bernard  │ Paris      │ ← Ligne 5
└────┴──────────┴────────────┘

Index sur ville :
┌────────────┬──────────┐
│ ville      │ position │
├────────────┼──────────┤
│ Lyon       │ Ligne 2  │
│ Marseille  │ Ligne 4  │
│ Paris      │ Ligne 1  │
│ Paris      │ Ligne 3  │
│ Paris      │ Ligne 5  │
└────────────┴──────────┘

Lorsqu’on exécute SELECT * FROM utilisateur WHERE ville = 'Paris' :

Sans index : le SGBD parcourt toutes les lignes (5 lignes).
Avec index : le SGBD consulte l’index, trouve les positions des lignes correspondantes (3 lignes), et accède directement à ces lignes.

Types d’index

1. Index B-tree (le plus courant)

La plupart des SGBD utilisent des arbres B-tree (Balanced Tree) pour structurer les index. C’est un type d’index équilibré qui permet des recherches rapides, même avec un grand nombre de données.

2. Index HASH

Utilisé principalement pour les comparaisons d’égalité (=). Très rapide pour ce type de recherche, mais inadapté pour les comparaisons de plage (>, <, BETWEEN).

3. Index Full-Text

Spécialisé dans la recherche de mots-clés dans de longs textes. Utilisé pour les requêtes de recherche plein texte (MATCH ... AGAINST en MySQL, tsvector en PostgreSQL).

4. Index spatial

Utilisé pour les données géographiques (coordonnées GPS, géométries). Permet des recherches comme « points dans un rayon donné ».

Avantages et inconvénients des index

Avantages

Amélioration des performances de lecture : les requêtes SELECT utilisant des conditions WHERE, JOIN, ORDER BY ou GROUP BY sur les colonnes indexées sont beaucoup plus rapides.
Réduction du coût des opérations de tri : un index ordonné permet d’éviter un tri supplémentaire (ORDER BY).
Accélération des contraintes d’unicité : la contrainte UNIQUE est automatiquement indexée pour garantir rapidement l’absence de doublons.

Inconvénients

Espace disque supplémentaire : chaque index occupe de l’espace. L’index peut parfois être plus grand que la table elle-même.
Ralentissement des opérations d’écriture : chaque INSERT, UPDATE ou DELETE doit mettre à jour l’index simultanément. Plus il y a d’index, plus les écritures sont lentes.
Maintenance nécessaire : les index doivent être entretenus (reconstruction, défragmentation) pour maintenir leurs performances.
Choix complexe : mal choisir un index peut être pire que de ne pas en avoir (surcoût pour des bénéfices faibles ou nuls).

Quand utiliser un index ?

Cas recommandés

Situation	Recommandation
Colonnes utilisées dans `WHERE` fréquemment	Index recommandé
Colonnes utilisées dans `JOIN`	Index recommandé (sur la colonne de jointure)
Colonnes utilisées dans `ORDER BY`	Index recommandé (permet d’éviter un tri explicite)
Colonnes utilisées dans `GROUP BY`	Index recommandé
Colonnes avec des valeurs uniques ou presque uniques	Index très efficace
Colonnes avec des contraintes `UNIQUE` ou `PRIMARY KEY`	Index automatiquement créé

Cas déconseillés

Situation	Recommandation
Colonnes rarement utilisées dans les requêtes	Index déconseillé (coût inutile)
Colonnes avec des valeurs très peu distinctes (ex: `sexe`, `pays`)	Index peu efficace (faible sélectivité)
Tables très petites (< 1000 lignes)	Index inutile (le parcours complet est plus rapide)
Colonnes fréquemment mises à jour	Index déconseillé (surcoût des mises à jour)

Création automatique d’index

Dans la plupart des SGBD, deux types d’index sont créés automatiquement :

Clé primaire (PRIMARY KEY) : un index unique est automatiquement créé sur la colonne (ou le groupe de colonnes) qui constitue la clé primaire.
Clé unique (UNIQUE) : un index unique est automatiquement créé pour garantir l’unicité.

CREATE TABLE utilisateur (
    id INT PRIMARY KEY,           -- Index automatique sur id
    email VARCHAR(255) UNIQUE,    -- Index automatique sur email
    nom VARCHAR(100)
);

Performance : un exemple concret

Considérons une table de 1 million de clients.

Sans index :

SELECT * FROM client WHERE nom = 'Durand';

Le SGBD doit parcourir les 1 million de lignes pour trouver les correspondances → opération lente (plusieurs secondes).

Avec index :

CREATE INDEX idx_client_nom ON client(nom);
SELECT * FROM client WHERE nom = 'Durand';

Le SGBD parcourt l’index (une structure arborescente) pour trouver les positions des lignes contenant ‘Durand’ → opération rapide (quelques millisecondes).

Structure physique d’un index

Un index B-tree (le plus courant) est une structure hiérarchique :

          [50]
         /    \
      [25]    [75]
     /   \   /   \
   [10] [40] [60] [90]

Chaque nœud contient des valeurs et des pointeurs vers d’autres nœuds ou vers les lignes de la table. La recherche dans un index B-tree s’effectue en O(log n), ce qui est extrêmement rapide même pour de très grandes tables.

Bonnes pratiques générales

Indexez les colonnes utilisées dans les clauses WHERE, JOIN, ORDER BY et GROUP BY.
Préférez les index sur les colonnes avec une grande sélectivité (valeurs uniques ou presque uniques) plutôt que sur des colonnes avec peu de valeurs distinctes.
Évitez les index inutiles : chaque index alourdit les opérations d’écriture.
Analysez les requêtes lentes avec EXPLAIN (voir chapitre 45) pour identifier les opportunités d’indexation.
Considérez les index composites (sur plusieurs colonnes) pour les requêtes qui filtrent sur plusieurs colonnes simultanément.
Maintenez les index : reconstruisez ou réorganisez périodiquement les index sur les grandes tables (selon votre SGBD).
Utilisez les index uniquement lorsqu’ils apportent un bénéfice mesurable : testez avec et sans index, notamment sur les environnements de production.

Prochain chapitre

Vous avez maintenant compris ce que sont les index et leur importance pour les performances. Passons maintenant à la pratique avec la création d’index.

👉 Chapitre 44 : CREATE INDEX – Créer un index

Bonne continuation !
Junior TSAFACK – 08/08/2026