Vues matérialisées SQL : boostez vos performances

Les vues matérialisées SQL permettent de stocker physiquement le résultat d'une requête sur disque, contrairement aux vues classiques qui recalculent tout à chaque appel. Résultat : des temps de réponse divisés par 10, 100, voire 1 000 sur des datasets volumineux. Si vous travaillez sur des pipelines analytiques ou si vous passez un entretien data, comprendre les vues matérialisées est un atout décisif.

Dans cet article, vous allez découvrir comment créer une vue matérialisée, choisir la bonne stratégie de rafraîchissement, identifier les cas où elles s'imposent — et ceux où elles nuisent. Les exemples couvrent PostgreSQL (le moteur le plus utilisé en entretien technique) avec des notes sur Oracle et Snowflake.

Vue classique vs vue matérialisée : quelle différence concrète ?

Une vue SQL classique est simplement un alias de requête. Chaque fois que vous l'interrogez, le moteur exécute la requête sous-jacente en temps réel. Sur une table de 10 millions de lignes avec plusieurs jointures, cela peut prendre plusieurs secondes — voire minutes.

Une vue matérialisée (ou materialized view) exécute la requête une seule fois et sauvegarde le résultat dans une structure analogue à une table. Les lectures suivantes lisent ce résultat pré-calculé, sans retoucher les tables sources.

La contrepartie est simple : les données ne sont plus forcément à jour. Si une commande est insérée dans orders à 14h00 et que la vue n'est rafraîchie qu'à minuit, la commande n'apparaît pas avant le lendemain. Ce compromis fraîcheur vs performance est au cœur du sujet.

Syntaxe de création dans PostgreSQL

La création d'une vue matérialisée suit une syntaxe proche de celle d'une vue classique, avec le mot-clé MATERIALIZED en plus :

CREATE MATERIALIZED VIEW ventes_mensuelles AS
SELECT
    DATE_TRUNC('month', commande_date) AS mois,
    categorie,
    SUM(montant)                        AS chiffre_affaires,
    COUNT(*)                            AS nb_commandes
FROM commandes
JOIN produits USING (produit_id)
GROUP BY 1, 2;

Pour interroger la vue, vous utilisez un SELECT classique :

SELECT *
FROM ventes_mensuelles
WHERE mois >= '2026-01-01'
ORDER BY mois, chiffre_affaires DESC;

Le moteur lit uniquement la vue stockée — les tables commandes et produits ne sont pas touchées.

Rafraîchir la vue

Dans PostgreSQL, le rafraîchissement est manuel ou planifié via pg_cron :

-- Rafraîchissement complet (bloque les lectures pendant l'opération)
REFRESH MATERIALIZED VIEW ventes_mensuelles;

-- Rafraîchissement sans blocage (nécessite un index UNIQUE sur la vue)
REFRESH MATERIALIZED VIEW CONCURRENTLY ventes_mensuelles;

L'option CONCURRENTLY est précieuse en production : les utilisateurs continuent de lire l'ancienne version pendant que la nouvelle se construit. Pour l'activer, vous devez d'abord créer un index unique sur la vue.

Indexer une vue matérialisée

Puisqu'une vue matérialisée se comporte comme une table, vous pouvez y créer des index exactement de la même façon :

-- Index unique requis pour REFRESH CONCURRENTLY
CREATE UNIQUE INDEX ON ventes_mensuelles (mois, categorie);

-- Index supplémentaire pour les filtres fréquents
CREATE INDEX ON ventes_mensuelles (categorie);

Comme pour les tables classiques, un index accélère les lectures mais ralentit les rafraîchissements. Si vous rafraîchissez toutes les heures sur une vue très large, limitez le nombre d'index. Pour approfondir la logique d'indexation, consultez notre guide sur les index SQL et l'optimisation des performances.

Comparatif des stratégies de rafraîchissement

La stratégie de rafraîchissement est souvent le premier point que les recruteurs explorent après la syntaxe de base. Le tableau ci-dessous résume les options selon les principaux moteurs :