Sur de petits volumes, presque toutes les requêtes sont rapides. Les vrais défis de performance apparaissent à grande échelle — des millions de lignes, des jointures multiples, du trafic concurrent élevé. Voici une démarche structurée pour les aborder.

On small datasets, almost every query is fast. Real performance challenges show up at scale — millions of rows, multiple joins, high concurrent traffic. Here's a structured approach to tackling them.

Commencer par le plan d'exécution

Start With the Execution Plan

Avant d'optimiser à l'aveugle, utilisez EXPLAIN (ou EXPLAIN ANALYZE) pour voir comment le moteur exécute réellement votre requête : quels index sont utilisés, où le temps est dépensé.

Before optimizing blindly, use EXPLAIN (or EXPLAIN ANALYZE) to see how the engine actually executes your query: which indexes are used, where the time is spent.

EXPLAIN ANALYZE
SELECT c.nom, SUM(co.montant)
FROM clients c
JOIN commandes co ON co.client_id = c.id
WHERE co.date_commande > '2026-01-01'
GROUP BY c.nom;

EXPLAIN ANALYZE
SELECT c.name, SUM(o.amount)
FROM customers c
JOIN orders o ON o.customer_id = c.id
WHERE o.order_date > '2026-01-01'
GROUP BY c.name;

Repérez surtout les full table scans sur de grandes tables : c'est souvent le premier signal qu'un index manque.

Watch especially for full table scans on large tables: that's often the first sign of a missing index.

Index composites et ordre des colonnes

Composite Indexes and Column Order

Un index composite couvre plusieurs colonnes, mais son efficacité dépend de l'ordre : mettez d'abord les colonnes filtrées par égalité, puis celles filtrées par plage.

A composite index covers several columns, but its efficiency depends on the order: put equality-filtered columns first, range-filtered ones after.

CREATE INDEX idx_commandes_client_date
  ON commandes (client_id, date_commande);

CREATE INDEX idx_orders_customer_date
  ON orders (customer_id, order_date);

Le partitionnement

Partitioning

Pour des tables massives (souvent avec un historique dans le temps), le partitionnement divise physiquement la table — par exemple par mois — pour que les requêtes n'aient à balayer que les partitions pertinentes.

For massive tables (often with a time-based history), partitioning physically splits the table — for example by month — so queries only need to scan the relevant partitions.

CREATE TABLE commandes (
  id INT, client_id INT, montant DECIMAL, date_commande DATE
) PARTITION BY RANGE (date_commande);

CREATE TABLE commandes_2026_01 PARTITION OF commandes
  FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

CREATE TABLE orders (
  id INT, customer_id INT, amount DECIMAL, order_date DATE
) PARTITION BY RANGE (order_date);

CREATE TABLE orders_2026_01 PARTITION OF orders
  FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

Mise en cache et données précalculées

Caching and Precomputed Data

Pour des lectures très fréquentes sur des données qui changent peu, une vue matérialisée ou un cache applicatif (Redis, par exemple) évite de recalculer le même résultat à chaque requête.

For very frequent reads on data that changes rarely, a materialized view or an application-level cache (Redis, for example) avoids recomputing the same result on every request.

Points clés à retenir

Key Takeaways

• Commencez toujours par EXPLAIN ANALYZE avant d'ajouter des index ou de refactoriser
• L'ordre des colonnes dans un index composite change radicalement son efficacité
• Le partitionnement et la mise en cache ciblent des problèmes différents : volume de données vs fréquence de lecture

• Always start with EXPLAIN ANALYZE before adding indexes or refactoring
• Column order in a composite index radically changes its effectiveness
• Partitioning and caching target different problems: data volume vs. read frequency