Index et transactions
Index de recherche et atomicité BEGIN/COMMIT.
Objectifs
À la fin de cette leçon, vous saurez :
- expliquer à quoi sert un index ;
- décrire les trois commandes d'une transaction ;
- justifier les transactions par le cas du virement bancaire.
L'index : l'annuaire de la base
Sans index, WHERE email = 'ana@exemple.fr' force la lecture de chaque ligne (scan complet) : sur un million d'utilisateurs, un million de comparaisons.
Un index maintient en permanence une structure triée sur une colonne :
sans index → lire toutes les lignes, comparer une par une
avec index → sauter directement à la bonne zone (comme un annuaire)
CREATE INDEX idx_tasks_user ON tasks(user_id);
Coût à connaître : chaque écriture doit aussi mettre l'index à jour. On indexe donc les colonnes recherchées (FK, emails, slugs), pas tout. Les clés primaires et UNIQUE ont déjà leur index automatique.
Les transactions : tout ou rien
Opération classique : transférer 10 € d'Ana vers Bob.
UPDATE comptes SET solde = solde - 10 WHERE id = 1; -- Ana
-- ⚡ crash ici → 10 € disparus !
UPDATE comptes SET solde = solde + 10 WHERE id = 2; -- Bob
La transaction enveloppe les deux écritures en bloc atomique :
BEGIN;
UPDATE comptes SET solde = solde - 10 WHERE id = 1;
UPDATE comptes SET solde = solde + 10 WHERE id = 2;
COMMIT; -- les deux s'appliquent
-- ou ROLLBACK; -- aucune ne s'applique (annulation totale)
| Commande | Effet |
|---|---|
| BEGIN | ouvre la transaction |
| COMMIT | valide définitivement |
| ROLLBACK | annule tout ce qui a été fait depuis BEGIN |
Règle d'architecture : toute opération qui modifie plusieurs tables mérite une transaction. Votre future application en fera usage systématiquement (le driver pg expose client.query('BEGIN')... exactement comme votre plateforme Devmind gère ses imports).
Exercice
- Quelles colonnes de users/tasks méritent un index ? Pourquoi ?
- Un inscription + envoi d'email de confirmation : où placer la transaction ?
- Que se passe-t-il si ROLLBACK survient après un INSERT réussi ?
Résumé
- Index = recherche rapide contre écriture légèrement plus chère.
- BEGIN/COMMIT/ROLLBACK : atomicité pour les opérations multi-écritures.
- Indexer ce qu'on cherche ; transactionner ce qui doit réussir ensemble.
Correction disponibleCherchez d’abord par vous-même.Voir la correction
Correction
Réponses détaillées
Question 1. tasks.user_id (toutes vos requêtes JOIN/filtre passent par là), users.email (déjà indexé car UNIQUE), éventuellement tasks.fait si filtrage fréquent. Pas besoin d'index sur titre tant que personne ne cherche dedans.
Question 2. Seulement autour des écritures en base. L'envoi d'email — lent et faillible — se fait APRÈS le COMMIT ; sinon une panne mail annulerait l'inscription, et une panne base après email créerait un email mensonger. Le pattern professionnel : transaction courte en base, puis effets externes.
Question 3. La ligne insérée disparaît complètement : dans une transaction non validée, rien n'est visible ni conservé. C'est précisément le but.