@sql-optimizerLe démineur SQL — rewrite + indexes + EXPLAIN reasoning

Le problème qu'il résout

Ton dashboard met 4.2 secondes à charger. Tu as tracé : c'est une requête sur une table de 4 millions de lignes. Tu pourrais demander à un DBA — mais tu n'en as pas. Tu pourrais lire 30 articles sur les indexes Postgres — mais tu n'as pas 3 heures.

@sql-optimizer regarde ton EXPLAIN, te dit exactement pourquoi c'est lent (seq scan ? sort sans index ? N+1 caché ?), et propose le CREATE INDEX précis qui passera de 4.2s à 4ms.

Comment il bosse

1. Tu lui donnes la requête + le schema + l'EXPLAIN ANALYZE (si possible).
2. Il identifie le goulot via 10 diagnostics : seq scan, nested loop, sort sans index, predicate mal placé, OR qui défait l'index, function sur indexed column, N+1 dressé en SQL.
3. Il propose un rewrite si la requête peut être réécrite mieux.
4. Il propose les indexes exacts (avec colonnes et ordre) à créer.
5. Il chiffre l'impact attendu (de seq scan 4.2s → index scan 4-8ms).
6. Il flag les tradeoffs (coût d'écriture d'un index, etc.).

Exemple concret

Tu tapes

›@sql-optimizer cette requête prend 4.2s :

SELECT o.*, u.email FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.status = 'pending' AND o.created_at > NOW() - INTERVAL '7 days'
ORDER BY o.created_at DESC LIMIT 50;

Postgres 15. Voici schemas + EXPLAIN ANALYZE :
[colle]

Tu obtiens

## Diagnosis
Seq scan sur orders (4M rows). L'index (status) seul ne suffit pas —
Postgres choisit le seq scan car le filtre composite n'est pas indexé.

## Index recommendation
CREATE INDEX idx_orders_status_created ON orders (status, created_at DESC)
WHERE status = 'pending';

(Index partiel : 50× plus petit qu'un index full)

## Expected impact
Seq scan (4.2s) → Index Scan (4-8 ms) — ~500× plus rapide

## Caveats
- Insertion = écriture additionnelle dans l'index (négligeable).
- Si 'pending' > 30% des orders, l'index partiel devient moins utile.

Pourquoi tu vas l'aimer

Quand l'utiliser

Combine avec ces agents

Questions fréquentes