PmaControl logo PmaControl
Ressources › Centre d'optimisation MySQL › Paramètres de performance MySQL

Paramètres de performance MySQL

Documentation Markdown structurée pour diagnostiquer, mesurer et optimiser MySQL.

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

Les paramètres MySQL pilotent la mémoire, les threads, les caches, la durabilité et l'I/O. Ils doivent être documentés par rôle plutôt que modifiés comme une liste magique.

Familles de paramètres

  • Mémoire globale: innodb_buffer_pool_size, key_buffer_size, caches de tables.
  • Mémoire par session: sort_buffer_size, join_buffer_size, read_rnd_buffer_size, tmp_table_size.
  • I/O InnoDB: flush, redo log, page cleaners, threads de lecture et écriture.
  • Connexions: max_connections, thread cache, limites de fichiers.
  • Compatibilité historique: query cache, MyISAM et paramètres obsolètes.

Méthode

Commencer par SHOW VARIABLES et SHOW GLOBAL STATUS, puis comparer les valeurs au comportement observé. Une valeur haute peut aggraver la mémoire totale si elle est allouée par connexion.

Voir aussi: Index des paramètres.

Examiner valeurs effectives et portée

Partez de l’identité et des valeurs réellement utilisées par le processus. Les fichiers seuls peuvent manquer des options de lancement, valeurs persistées ou changements à chaud. Les valeurs globales par défaut et celles d’une session existante peuvent différer. Notez unités, portée, source, caractère dynamique ou besoin de redémarrage et valeur initiale. Cet inventaire omet les variables absentes de la version installée.

SELECT VERSION() AS server_version, @@version_comment AS distribution;
SHOW GLOBAL VARIABLES WHERE Variable_name IN (
  'innodb_buffer_pool_size', 'innodb_log_buffer_size',
  'innodb_redo_log_capacity', 'innodb_log_file_size',
  'innodb_flush_log_at_trx_commit', 'sync_binlog',
  'max_connections', 'thread_cache_size', 'table_open_cache',
  'sort_buffer_size', 'join_buffer_size', 'tmp_table_size',
  'max_heap_table_size', 'internal_tmp_mem_storage_engine',
  'temptable_max_ram', 'temptable_max_mmap'
);
SHOW SESSION VARIABLES WHERE Variable_name IN (
  'sort_buffer_size', 'join_buffer_size', 'tmp_table_size',
  'max_heap_table_size'
);

Relier chaque famille aux mesures

Famille Comment confirmer Compromis à évaluer
Buffer pool Jeu actif, deltas de lecture, RSS Bénéfice du cache contre réserve mémoire système
Capacité redo Débit d’écriture, attentes redo, checkpoints Espace disque et comportement de reprise
Buffers de session Tris, jointures et concurrence active réels Allocations à la demande et opérateurs multiples
Limites de connexions et tables Refus, création de threads, ouvertures de tables Plus de capacité peut accroître mémoire et contention
Durabilité des commits Latence des commits et tolérance aux pannes requise Débit contre risque de perte de données acquittées

Budgéter selon les allocations

Ne multipliez pas tous les buffers par max_connections pour annoncer la RAM réellement consommée. Beaucoup sont alloués à la demande, et une requête peut avoir plusieurs buffers de jointure ou tables temporaires. Séparez mémoire globale, coût des sessions connectées et mémoire des requêtes actives ; gardez un scénario de stress comme borne à examiner. Incluez OS, autres services et instrumentation, puis comparez modèle, RSS mesurée et pression mémoire.

TempTable MySQL possède un budget RAM partagé via temptable_max_ram ; depuis MySQL 8.0.28, tmp_table_size limite aussi chaque table interne TempTable. Les tables internes basées sur MEMORY utilisent le minimum de tmp_table_size et max_heap_table_size. Ces règles dépendent du moteur et de la version. La capacité redo est du disque, innodb_log_buffer_size de la RAM : ne comptez pas les deux comme mémoire.

Respecter versions et persistance

MySQL 8.0.30 a introduit innodb_redo_log_capacity ; les versions précédentes utilisent les variables de taille des fichiers redo. Le query cache concerne les anciennes versions MySQL et a été supprimé dans MySQL 8. MariaDB possède son propre cycle de variables, à vérifier dans son manuel. Ne recopiez jamais une configuration contenant des variables inconnues ou supprimées sans validation.

Pour chaque changement, vérifiez s’il touche les sessions existantes, nouvelles ou exige un redémarrage. Un changement global à chaud n’est pas forcément persistant ; SET PERSIST MySQL écrit une configuration distincte. Alignez valeurs actives et attendues au redémarrage, documentez leur rollback et testez reconnexion/redémarrage dans un environnement maîtrisé. Comparez une hypothèse à la fois sur la même charge et préservez la durabilité requise.

Poursuivre le diagnostic

Références officielles