🎯 1) Cadrage & KPIs

Objectif : Définir les *Service Level Objectives* (SLO), le budget de ressources, et les priorités d'optimisation pour MariaDB.

1.1

Objectifs & SLOs

Définir la latence p95 cible, les QPS attendus et le type de workload (OLTP/OLAP).

SLO p95 QPS

1.2

Volumétrie & Budget

Collecter RAM, vCPU, type de disque et taille du dataset (total vs données "chaudes").

RAM InnoDB Dataset

1.3

Priorités & Quick Wins

Identifier les top requêtes lentes et les goulots évidents (ex: absence de pooler).

slow_log Pooler

1.1 Objectifs & SLOs

Collecte des Objectifs

Qu'est-ce qui est considéré comme "rapide" ou "lent" ?

Métrique	Cible / Valeur
SLO Latence (p95)	ex: 200 ms
QPS (moyen / pic)	ex: 5000 / 15000
Type de Workload	OLTP / OLAP / Mixte
Objectif du Tuning	Réduire latence / Augmenter QPS

Contexte & Importance

Sans SLO (Service Level Objective), le tuning est "aveugle". On ne peut pas savoir si 200ms est un succès ou un échec pour *cette* application.

Pourquoi p95 ?

La moyenne est une métrique trompeuse (lissée par trop de requêtes rapides). Le p95 (95e percentile) est bien meilleur : il signifie "95% de mes requêtes sont *plus rapides* que X ms". C'est ce que ressentent vos utilisateurs.

Workload

OLTP (Transactionnel) : beaucoup de petites requêtes (INSERT, UPDATE, SELECT by ID). Priorité à la latence basse.
OLAP (Analytique) : peu de grosses requêtes (JOINs, agrégats). Priorité au débit (throughput).

1.2 Volumétrie & Budget

Ressources & Données

Quel est notre "budget" de ressources ?

Ressource	Valeur
RAM (serveur)	ex: 64 Go
vCPU (serveur)	ex: 16 vCPU
Stockage (type)	ex: SSD NVMe / Cloud EBS gp3
Taille totale dataset	ex: 200 Go
Taille active (hot data)	ex: 30 Go
Version MariaDB	ex: 10.6.12, 10.11.5

Contexte & Importance

Le tuning est l'art d'allouer un budget (RAM, CPU, I/O) de la manière la plus efficace.

RAM & InnoDB

La RAM est la ressource n°1 pour MariaDB. La taille du InnoDB Buffer Pool (innodb_buffer_pool_size) en dépendra directement. C'est le cache principal des données et index.

Dataset Actif

La taille des "données chaudes" (actives) est souvent plus importante que la taille totale. Idéalement, l'InnoDB Buffer Pool doit être capable de contenir 100% de ce dataset actif pour minimiser les lectures disque.

1.3 Priorités & Quick Wins

Problèmes & Contraintes

Quels sont les problèmes actuels et les gains faciles ?

Point	État Actuel
Top 5 requêtes lentes	(Identifier via `slow_log`)
Connexions max (app)	ex: 1000
Pooler (ProxySQL/MaxScale)	Oui / Non
Contraintes ops	ex: Pas de redémarrage

Contexte & Importance

Ne pas tout optimiser. Suivre la loi de Pareto (règle 80/20) :
"20% des requêtes causent 80% de la charge."

Priorité n°1

Identifier ces "top requêtes" (via le slow_query_log et pt-query-digest) est la première étape de toute optimisation.

Quick Win n°1 : Le Pooler

Si Pooler = Non et Connexions > 200, la base de données passe son temps à gérer des connexions au lieu de traiter des requêtes. L'ajout d'un pooler (ProxySQL, MariaDB MaxScale) est souvent le gain de performance le plus spectaculaire et le plus simple à mettre en place.