Les index SQL : à quoi ça sert et comment les créer

Votre application fonctionnait parfaitement en développement. Puis, en production, la base a grossi — des centaines de milliers de lignes — et soudain, une requête toute simple met plusieurs secondes à répondre. Neuf fois sur dix, le coupable est le même : un index manquant. Les index sont l’outil le plus efficace pour accélérer les requêtes d’une base de données, et pourtant ils restent mal compris. Cet article explique à quoi ils servent, comment ils fonctionnent, comment en créer, et surtout quand en mettre — et quand s’en abstenir.

Le problème : la recherche sans index

Imaginez une table clients contenant des centaines de milliers de lignes. Vous cherchez un client par son adresse e-mail :

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

Sans index, la base de données n’a pas d’autre choix que de lire toutes les lignes de la table, une par une, en vérifiant à chaque fois si l’e-mail correspond. C’est ce qu’on appelle un balayage complet de table (full table scan). Sur une petite table, c’est instantané. Sur une grosse table, c’est catastrophique : le temps de réponse augmente proportionnellement au nombre de lignes.

Pour donner un ordre de grandeur concret : sur une table de 200 000 lignes, une recherche de ce type sans index prend une quinzaine de millisecondes. Avec un index approprié, la même recherche descend à quelques microsecondes — soit, dans un test réel, environ 2 800 fois plus rapide. Et l’écart se creuse encore à mesure que la table grandit.

À quoi sert un index ?

Un index de base de données fonctionne exactement comme l’index d’un livre. Pour trouver un sujet dans un ouvrage de 800 pages, vous n’allez pas lire toutes les pages une par une : vous consultez l’index à la fin, qui est trié par ordre alphabétique, vous y trouvez le sujet et le numéro de page, et vous sautez directement au bon endroit. L’index d’une base fait la même chose : c’est une structure séparée, triée, qui permet de retrouver rapidement les lignes correspondant à une valeur, sans parcourir toute la table.

Autre analogie parlante : l’annuaire téléphonique. Trié par nom de famille, il vous permet de trouver « Dupont » en quelques secondes. Mais si l’on vous demandait de retrouver toutes les personnes dont le numéro se termine par « 47 », vous devriez lire tout l’annuaire — car il n’est pas trié par numéro. C’est exactement la différence entre une colonne indexée et une colonne qui ne l’est pas.

Comment ça marche, concrètement ?

Un index est une structure de données séparée, maintenue par la base à côté de la table. La plupart des index reposent sur une structure appelée arbre B (ou B-tree, pour balanced tree, arbre équilibré). Sans entrer dans les détails techniques, retenez l’essentiel : cette structure stocke les valeurs de la colonne indexée dans un ordre trié, avec un pointeur vers la ligne complète correspondante.

L’intérêt de l’arbre équilibré est mathématique. Là où un balayage complet doit examiner les lignes une à une (si la table a un million de lignes, jusqu’à un million de vérifications), un index permet de trouver une valeur en un nombre d’étapes qui croît de façon logarithmique. En pratique, retrouver une valeur dans un index sur un million de lignes ne demande qu’une poignée d’étapes — pas un million. C’est ce qui explique les gains de performance spectaculaires.

Comme l’index est trié, il accélère aussi naturellement les tris (ORDER BY) et les recherches par plage (BETWEEN, >, <) sur la colonne indexée.

Créer un index

Bonne nouvelle : la syntaxe de création d’un index est quasi identique sur tous les SGBD (Oracle, MySQL/MariaDB, PostgreSQL, SQL Server). La commande de base est :

CREATE INDEX idx_clients_email ON clients (email);

Cette commande crée un index nommé idx_clients_email sur la colonne email de la table clients. Une convention répandue consiste à nommer ses index idx_{table}_{colonne}, pour les identifier facilement plus tard.

L’index unique. Si les valeurs de la colonne doivent être toutes différentes (comme un e-mail ou un numéro de sécurité sociale), on crée un index unique, qui accélère les recherches et garantit l’absence de doublons :

CREATE UNIQUE INDEX idx_clients_email ON clients (email);

L’index composite (sur plusieurs colonnes) est utile quand on filtre souvent sur une combinaison de colonnes :

CREATE INDEX idx_commandes_statut_date ON commandes (statut, date_commande);

Mais attention, l’ordre des colonnes est crucial — nous y revenons plus bas. À noter enfin : la clé primaire d’une table est automatiquement indexée par la base ; inutile de créer un index dessus.

Quand créer un index ?

Un index n’est pas gratuit (nous verrons pourquoi), donc on ne les met pas au hasard. Les bons candidats sont les colonnes qui apparaissent fréquemment dans :

• Les clauses WHERE : les colonnes sur lesquelles vous filtrez souvent (rechercher par e-mail, par nom, par référence…).
• Les jointures (JOIN) : les colonnes qui relient deux tables. Indexer les clés étrangères accélère considérablement les jointures.
• Les tris (ORDER BY) et les regroupements (GROUP BY) : un index évite à la base de trier les résultats à chaque requête.

La règle d’or : commencez par identifier vos requêtes les plus lentes et les plus fréquentes, et créez des index ciblés pour elles. Indexer en fonction des besoins réels, pas « au cas où ».

Quand éviter les index ?

C’est le point que les débutants négligent : les index ont un coût. En créer trop est contre-productif. Trois raisons de ne pas indexer à tout-va :

Le coût en écriture. Chaque fois que vous insérez, modifiez ou supprimez une ligne, la base doit mettre à jour tous les index de la table. Plus il y a d’index, plus les écritures sont lentes. Sur une table très sollicitée en écriture (journaux, événements), multiplier les index peut faire plus de mal que de bien.

Le coût en espace. Un index est une structure de données supplémentaire, qui occupe de l’espace disque. Sur de grosses tables, les index peuvent représenter une part significative du stockage.

La faible utilité sur certaines colonnes. Indexer une colonne à très faible cardinalité (peu de valeurs distinctes — par exemple une colonne « actif/inactif » avec seulement deux valeurs) apporte peu, car l’index ne permet pas d’éliminer assez de lignes. L’index est le plus efficace sur des colonnes où les valeurs sont variées.

En résumé : indexez les colonnes de recherche, de jointure et de tri sur les tables où la lecture domine, et restez économe sur les tables massivement en écriture.

Les pièges à connaître

Quelques erreurs classiques réduisent à néant l’efficacité d’un index.

Appliquer une fonction sur la colonne indexée. Si vous écrivez WHERE YEAR(date_commande) = 2026, la base doit calculer YEAR() sur chaque ligne et ne peut pas utiliser l’index sur date_commande. La solution : réécrire en plage, WHERE date_commande >= '2026-01-01' AND date_commande < '2027-01-01', qui, elle, exploite l’index. C’est un piège que nous détaillons d’ailleurs pour les dates dans notre article dédié.

Le mauvais ordre des colonnes dans un index composite. Un index sur (statut, date_commande) aide les requêtes qui filtrent sur statut, ou sur statut ET date_commande — mais pas une requête qui filtre uniquement sur date_commande. C’est la « règle du préfixe le plus à gauche » : un index composite ne sert que si la requête utilise ses colonnes de gauche à droite. Placez en premier la colonne la plus utilisée dans vos filtres.

Les index inutilisés. Avec le temps, les besoins évoluent et certains index ne servent plus à rien : ils continuent de ralentir les écritures et d’occuper de l’espace, sans bénéfice. Il est sain d’auditer périodiquement ses index et de supprimer les inutiles avec DROP INDEX.

En résumé

Les index de base de données, en quelques idées clés :

• Un index accélère les recherches en évitant le balayage complet de la table — comme l’index d’un livre évite de lire toutes les pages.
• La syntaxe est quasi universelle : CREATE INDEX nom ON table (colonne).
• Indexez les colonnes de WHERE, JOIN et ORDER BY ; la clé primaire l’est déjà.
• N’indexez pas à tout-va : chaque index ralentit les écritures et occupe de l’espace.
• Méfiez-vous des pièges : fonction sur colonne indexée, mauvais ordre d’un index composite, index oubliés.

Bien utilisés, les index transforment une base lente en base réactive, souvent sans changer une ligne de code applicatif. Mal utilisés, ils alourdissent les écritures sans rien accélérer. Le secret tient en une phrase : indexez en fonction de vos requêtes réelles, mesurez l’effet, et gardez le juste nécessaire.