Page d'évaluation performance

Cette page est une documentation originale PmaControl. Elle reprend une structure d'index pratique pour travailler sur l'optimisation MySQL, sans copier de contenu tiers ni dépendre d'un produit externe.

Objectif

La page d'évaluation performance agrège les signaux principaux d'un serveur MySQL dans une lecture unique. Elle sert à prioriser les actions, pas à remplacer l'analyse DBA.

Dimensions utiles

• Configuration: cohérence des variables avec la mémoire, le stockage et la charge.
• Requêtes: poids des requêtes lentes et des requêtes fréquentes.
• Schéma: index, clefs primaires, volumétrie et tables temporaires.
• Stabilité: redémarrages, erreurs de connexion, deadlocks, saturation de threads.
• Capacité: tendances CPU, I/O, QPS, connexions et espace disque.

Exemple de grille

A retenir

Une note globale n'a de valeur que si elle reste explicable. Chaque point doit pointer vers une métrique, une requête ou une configuration vérifiable.

Définir le périmètre évalué

Créez une évaluation datée par rôle serveur et charge représentative. Notez fenêtre, fraîcheur des données, version, topologie, limites matérielles et objectif métier. Incluez application et proxy pour évaluer la latence utilisateur. Serveur d’écriture, réplica de reporting et secours n’ont pas la même charge ni le même risque acceptables. Ce guide décrit une méthode de revue ; les tableaux sont des modèles, pas des mesures ni un score PmaControl calculé automatiquement.

SELECT NOW() AS observed_at, @@hostname AS hostname,
       VERSION() AS server_version, @@global.read_only AS read_only;
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Uptime', 'Questions', 'Threads_connected', 'Threads_running',
  'Connection_errors_max_connections', 'Innodb_log_waits',
  'Innodb_buffer_pool_reads', 'Innodb_buffer_pool_read_requests'
);

Construire une grille fondée sur des preuves

Marquez comme inconnue toute instrumentation absente, périmée ou désactivée. Une métrique manquante ne devient pas verte et ne vaut pas un zéro inventé. Séparez observation, interprétation et action proposée. Ratio de lectures physiques, pic historique de connexions et liste d’index inutilisés exigent un contexte de charge avant de devenir des constats.

Prioriser impact, urgence et confiance

• Critique : panne actuelle, stockage bientôt épuisé, perte ou exposition d’accès confirmée et inacceptable.
• Élevé : objectifs de latence/erreurs régulièrement dépassés ou pression croissante avec mécanisme confirmé.
• Planifié : coût ou risque mesurable sans impact actuel ; prévoir une validation maîtrisée.
• Inconnu : preuves insuffisantes ; affecter la collecte plutôt que déclarer un succès.

Rendre les résultats avant/après comparables

Gardez matériel, données, trafic, concurrence et caches comparables ; notez les écarts et répétez les essais. Les compteurs exigent deltas et contrôle des resets. Les moyennes de digests ne sont pas des percentiles clients. Publiez gains et régressions ensemble, gardez les preuves brutes et laissez les champs non mesurés vides ou inconnus. Définissez acceptation et rollback avant le test ; plus de débit avec plus d’échecs n’est pas automatiquement un progrès.

Clore la boucle avec une fiche de constat

Pour chaque constat, conservez serveur/requête concernés, horodatage, lien de preuve, confiance, impact métier, responsable, action, échéance, test d’acceptation et rollback. Après correction, joignez résultat mesuré et limites restantes ; revérifiez au pic et au cycle métier complet suivant. Ne clôturez pas uniquement parce qu’une variable ou un score global a changé.

Poursuivre le diagnostic

• Collectez les preuves avec les contrôles de santé, schéma et sécurité ; validez les actions par le tuning et la revue des paramètres.

Références officielles

• MySQL Performance Schema