Chercher un mot dans un livre sans table des matières oblige à tout parcourir page par page. Une base de données procède exactement de la même façon sur une colonne non indexée : elle examine chaque ligne une par une, une opération appelée balayage complet, coûteuse dès que la table grossit.
Où WordPress en pose déjà
Les tables natives en contiennent plusieurs par défaut : wp_postmeta indexe post_id et meta_key, wp_posts indexe entre autres post_name et post_status combiné à la date. C’est justement l’absence fréquente d’index sur meta_value qui rend les requêtes de type WP_Query avec meta_query potentiellement lentes sur un grand volume de contenus.
On crée un index avec l’instruction CREATE INDEX, ou directement dans la définition de table avec la clause KEY.
Exemple
CREATE INDEX idx_statut_date
ON wp_commandes (statut, date_creation);
Pièges fréquents
- Un index composite n’accélère une requête que si les colonnes filtrées suivent le même ordre que celui de sa déclaration, de gauche à droite.
- Trop d’index ralentit les insertions et mises à jour, chaque écriture devant maintenir toutes les structures associées : il faut indexer selon les requêtes réellement exécutées, pas par précaution systématique.
- La commande
EXPLAINplacée devant une requête SQL révèle si un index est effectivement utilisé, une vérification indispensable avant d’en ajouter un nouveau à l’aveugle. - Un index plein texte, distinct d’un index classique, permet des recherches par pertinence sur de longues colonnes de texte via
MATCH() AGAINST(), une piste souvent négligée pour accélérer une recherche WordPress native devenue trop lente.