Ce cas pratique combine les notions de ce chapitre pour décider quels index créer sur abonnes.

CREATE UNIQUE INDEX idx_email ON abonnes(email);
CREATE INDEX idx_statut_age ON abonnes(statut, age);
CREATE INDEX idx_nom ON abonnes(nom);

Justification, colonne par colonne :

1. email sert de recherche fréquente et doit rester unique : un index UNIQUE remplit les deux besoins à la fois.
2. Les requêtes filtrent souvent statut seul, ou statut et age ensemble : un index composite (statut, age), dans cet ordre, couvre les deux cas.
3. nom sert surtout à trier les résultats (ORDER BY nom) : un index simple sur nom accélère ce tri.

Aucun index séparé n'est nécessaire sur id : en tant que clé primaire, il est déjà indexé automatiquement.

À retenir :

• Choisir un index se décide à partir des requêtes réellement exécutées (WHERE, ORDER BY, jointures), pas colonne par colonne au hasard.
• Un index composite doit refléter l'ordre de filtrage réel des requêtes, en commençant par la colonne la plus souvent utilisée seule.
• Une colonne déjà couverte par une clé primaire n'a pas besoin d'un index supplémentaire.

À vous de jouer : cette table gagnerait-elle un index composite (age, statut) en plus de (statut, age) ? Dans quel cas précis serait-il utile ?