> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Retours d’expérience - vues matérialisées

> Exemples concrets de vues matérialisées, problèmes et solutions

*Ce guide fait partie d’une collection d’enseignements issus de rencontres de la communauté. Pour découvrir d’autres solutions et retours d’expérience concrets, vous pouvez [parcourir les contenus par problème spécifique](/docs/fr/resources/support-center/tips-and-tricks/community-wisdom).*
*Trop de parts ralentissent votre base de données ? Consultez le guide communautaire [Too Many Parts](/docs/fr/resources/support-center/tips-and-tricks/too-many-parts).*
*En savoir plus sur les [Vues matérialisées](/docs/fr/concepts/features/materialized-views/index).*

<div id="storage-antipattern">
  ## L'anti-pattern du stockage x10
</div>

**Problème réel en production :** *"Nous avions une vue matérialisée. La table brute de logs faisait environ 20 Go, mais la vue créée à partir de cette table de logs est montée à 190 Go, soit presque 10x la taille de la table brute. Cela s'est produit parce que nous créions une ligne par attribut, et chaque log peut avoir 10 attributs."*

**Règle :** Si votre `GROUP BY` crée plus de lignes qu'il n'en élimine, vous êtes en train de construire un index coûteux, pas une vue matérialisée.

<div id="mv-health-validation">
  ## Validation de la santé d’une vue matérialisée en production
</div>

Cette requête vous aide à prévoir si une vue matérialisée va compresser vos données ou les faire exploser avant sa création. Exécutez-la sur votre table et vos colonnes réelles pour éviter le scénario de « l’explosion à 190 Go ».

**Ce qu’elle montre :**

* **Faible ratio d’agrégation** (\<10 %) = Bonne MV, compression significative
* **Ratio d’agrégation élevé** (>70 %) = Mauvaise MV, risque d’explosion du stockage
* **Multiplicateur de stockage** = Dans quelle mesure votre MV sera plus grande ou plus petite

```sql theme={null}
-- Replace with your actual table and columns
SELECT 
    count() as total_rows,
    uniq(your_group_by_columns) as unique_combinations,
    round(uniq(your_group_by_columns) / count() * 100, 2) as aggregation_ratio
FROM your_table
WHERE your_filter_conditions;

-- If aggregation_ratio > 70%, reconsider your MV design
-- If aggregation_ratio < 10%, you'll get good compression
```

<div id="mv-problems">
  ## Quand les vues matérialisées deviennent un problème
</div>

**Signes avant-coureurs à surveiller :**

* La latence d'insertion augmente (des requêtes qui prenaient 10 ms prennent désormais plus de 100 ms)
* Les erreurs "Too many parts" apparaissent plus fréquemment
* Des pics de CPU se produisent pendant les opérations d'insertion
* Des timeouts d'insertion surviennent alors qu'ils ne se produisaient pas auparavant

Vous pouvez comparer les performances d'insertion avant et après l'ajout de MV à l'aide de `system.query_log` pour suivre l'évolution de la durée des requêtes.

<div id="video-sources">
  ## Sources vidéo
</div>

* [ClickHouse at CommonRoom - Kirill Sapchuk](https://www.youtube.com/watch?v=liTgGiTuhJE) - Source de l’étude de cas « trop enthousiaste à propos des vues matérialisées » et de « l’explosion de 20GB→190GB »