# Un site média avec 500 000 commentaires : l’architecture de base qui tient

> Un média historique doit conserver des années de commentaires sans ralentir les nouveaux articles. Choix de partitionnement et d'archivage plutôt que de suppression.

- Auteur : Clément Hadrot
- Publié le : 2026-01-01
- Mis à jour le : 2026-01-01
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/site-media-500000-commentaires-architecture-base/

## L’essentiel

- La table wp_comments souffre surtout des index mal alignés avec les requêtes
- Le partitionnement par date isole le trafic actif du volume historique
- L'archivage ne signifie pas suppression, juste un accès moins prioritaire

```
+------------------------+
| wp_comments (actif)    |  <- articles des 90 derniers jours
+------------------------+
           |
           v
+------------------------+
| wp_comments_archive     |  <- commentaires antérieurs, lecture seule
+------------------------+
           |
           v
+------------------------+
| Export froid (Parquet)  |  <- au-delà de 3 ans, hors base active
+------------------------+
```

Ce schéma résume l'architecture mise en place pour un média en ligne dont la table `wp_comments` avait dépassé les 500 000 lignes après une décennie de publication continue et de forte participation de sa communauté de lecteurs. Aucune suppression n'était envisageable : ces commentaires font partie du patrimoine éditorial du site, souvent cités et référencés dans des articles ultérieurs.

Le problème n'était pas le volume en lui-même, mais son effet sur les performances : chaque nouvel article publié voyait ses premiers commentaires s'afficher avec plusieurs secondes de latence, à cause de requêtes qui parcouraient l'intégralité de l'historique pour retrouver les entrées récentes. Voici l'architecture retenue, qui ne touche volontairement pas à la modération éditoriale des commentaires, sujet distinct traité séparément.

## Diagnostiquer la cause réelle de la lenteur

Une analyse des requêtes lentes via `EXPLAIN` a révélé que les index existants sur `wp_comments`, pensés pour un volume dix fois plus faible, ne correspondaient plus au pattern de requêtes réel du site. La requête de listage des commentaires par article, censée être rapide grâce à un index sur `comment_post_ID`, restait lente à cause d'un tri secondaire sur la date qui forçait un balayage complémentaire sur une portion importante de la table.

```
EXPLAIN SELECT * FROM wp_comments
WHERE comment_post_ID = 4821
ORDER BY comment_date DESC LIMIT 20;
-- Type: ref, mais Extra: Using filesort sur 500k lignes
```

## Première étape : un index composite adapté au pattern réel

Avant d'envisager tout partitionnement, un index composite couvrant à la fois la colonne de filtrage et la colonne de tri a déjà réduit significativement le temps de réponse, sans aucune modification de schéma majeure.

> L'essentiel à retenir : La table wp_comments souffre surtout des index mal alignés avec les requêtes ; Le partitionnement par date isole le trafic actif du volume historique ; L'archivage ne signifie pas suppression, juste un accès moins prioritaire

```
ALTER TABLE wp_comments
ADD INDEX idx_post_date (comment_post_ID, comment_date DESC);
```

Ce seul changement a fait passer le temps de la requête de listage de plusieurs secondes à quelques centaines de millisecondes. Mais le volume global continuait de peser sur les sauvegardes complètes de la base, dont la durée s'allongeait à chaque nouvelle publication.

## Séparer l'actif de l'historique par partitionnement logique

Plutôt qu'un partitionnement natif MySQL par plage de dates, complexe à maintenir avec les mécanismes internes de WordPress qui interrogent directement `wp_comments`, le choix retenu a été un partitionnement applicatif : une table `wp_comments` conservant uniquement les commentaires des quatre-vingt-dix derniers jours, et une table `wp_comments_archive` recevant automatiquement les entrées plus anciennes via une tâche cron nocturne.

- Table active limitée aux commentaires récents, taille contenue et index légers
- Table d'archive en lecture quasi exclusive, interrogée uniquement pour l'affichage d'anciens articles
- Tâche de bascule nocturne transférant les entrées dépassant le seuil de rétention actif
- Vue unifiée côté affichage pour ne pas casser l'expérience de lecture sur les vieux articles

## Archivage froid au-delà de trois ans

Pour les commentaires de plus de trois ans, rarement consultés mais devant rester accessibles pour la cohérence éditoriale, un export périodique au format Parquet vers un stockage objet économique complète le dispositif. Ces données restent réintégrables en base à la demande, mais ne pèsent plus sur les opérations quotidiennes ni sur les sauvegardes régulières.

| Niveau | Contenu | Fréquence d'accès |
| --- | --- | --- |
| Table active | 90 derniers jours | Élevée |
| Table archive | De 90 jours à 3 ans | Occasionnelle |
| Export froid | Plus de 3 ans | Rare |

> Un média qui construit son autorité depuis dix ans ne peut pas se permettre de traiter ses commentaires anciens comme une donnée jetable : l'architecture doit préserver l'accès, pas seulement la performance du jour.

## Résultat mesuré après mise en place

La requête de listage des commentaires sur un nouvel article est passée de plus de quatre secondes à environ 90 millisecondes. La durée des sauvegardes complètes de la base a diminué de plus de 60 %, la table active représentant désormais une fraction modeste du volume total historique.

## En résumé

Face à un volume de commentaires qui ne cesse de croître sur un site média établi, la suppression n'est jamais une option acceptable éditorialement. Le partitionnement applicatif entre données actives et données archivées, complété par un archivage froid au-delà de plusieurs années, permet de concilier conservation intégrale et performance quotidienne, sans jamais sacrifier l'un pour l'autre.