| Réglages pour améliorer les performances | ||||||||||||
| Les valeurs de taille de tampon, longueurs et taille
de piles sont données en octets. Vous pouvez spécifier des
valeurs avec un suffixe "K" ou "M" pour indiquer des
kilos-octets ou des mégas-octets. Par exemple, "16M" indique
16 mega-octets. La casse des lettres de suffixe est indifférente;
"16M" et "16m" sont équivalents. Notes Quand vous spécifier une taille de buffer, il n'y a pas de réservation de mémoire pour "bloquer" autant de place que ce que vous avez précisé. Cette taille est la taille maximum qui sera alloué. Si vos index occupent 2Mo et que donnez un "key_buffer_size" de 32Mo, seulement 2Mo seront pris au maximum pour ce buffer. Le cache de requête n'existe que pour les dernières versions 4. Les noms des variables pour les versions 3 sont signalés par "Précédemment". L'utilisation de "key_buffer_size" donne des améliorations substantielles. Ne passez pas à côté de cette fonction, disponible pour les versions 3 et 4. La mise en cache des requêtes permet de gagner un temps précieux sur l'usage de requêtes répétitives. Attention les requêtes doivent être identiques octet par octet pour être considérées similaires. Chacune des variables ci-dessous présente un intérêt, et son utilisation peut se ressentir immédiatement sur les performances. Mais ce ne sont pas les seules, référez vous à la documentation pour la liste complète. N'oubliez pas que ces valeurs sont lues au démarrage de MySql, il vous faudra arrêter et redémarrer MySql pour que les changements soit pris en compte Les informations ci-dessous ont été extraites et traduites par mes soins de la documentation de la version 4.0.3-beta de MySql pour Windows NT. bdb_cache_size Le tampon qui est alloué pour mettre en cache les index et les données des tables de type "BDB". bulk_insert_buffer_size (Précédemment "myisam_bulk_insert_tree_size") Les tables MyISAM utilisent un cache spécial de type "arbre" pour réaliser des insertions massives (comme `INSERT ... SELECT', `INSERT ... VALUES (...), (...), ...', et `LOAD DATA INFILE') plus rapides. Cette variable limite la taille du cache pour chaque processus. Affecter 0 à cette variable désactive cette optimisation. La valeur par défaut est 8 MO. join_buffer_size La taille du tampon qui est utilisé pour des jointures "intégrales" (jointures qui n'utilisent pas d'index). Le tampon est alloué une fois pour chaque jointure "intégrale" entre deux tables. Augmentez cette valeur pour obtenir une jointure "intégrale" quand on ajouter des index ne donne pas de résultat. (Normalement la meilleure façon d'obtenir des jointures rapides est d'ajouter des indexs bien placés). key_buffer_size Les blocs d'index sont mis en mémoire cache et partagés par tous les processus. "key_buffer_size" est la taille du tampon utilisé pour stocker les blocs d'index. Augmentez cette valeur pour obtenir une meilleur gestion des index (pour toute les lectures et les écritures multiples) au maximum de ce que vous pouvez vous permettre; 64Mo sur une machine de 256Mo qui fait fonctionner principalement MySQL est assez courant. Si cependant vous mettez une valeur trop importante (plus de 50% de votre mémoire totale) votre systême pourrait commencer à utiliser le cache sur disque (paging) et devenir extrêment lent. Rappelez vous que MySQL ne met pas en cache les lectures de données, vous devrez laissez de la place à votre systême pour le cache du systême de fichier. Vous pouvez vérifier les performances du cache d'index avec la commande "show status" et en examinant les variables "Key_read_requests", "Key_reads", "Key_write_requests", et "Key_writes". Le ratio "Key_reads/Key_read_request" devrait normalement être inférieur à 0.01. Le ratio "Key_write/Key_write_requests" est habituellement proche de 1 si vous utilisez principalement des "update" et des "delete". Il peut être beaucoup plus petit si vous tendez à faire des "update" qui affectent beaucoup de données à la fois, ou si vous utilisez "DELAY_KEY_WRITE". read_buffer_size (Précédemment "record_buffer") Chaque processus qui effectue un parcours séquentiel alloue un tampon de cette taille pour chaque table qu'il parcours. Si vous faites beaucoup de parcours séquentiels, vous pourriez augmenter cette valeur. record_rnd_buffer_size Quand des données sont lus après un tri, les données sont lus à travers ce tampon pour éviter des accès disques. Ce tampon peut beaucoup améliorer l'usage de "ORDER BY" si sa taille est importante. Comme cette variable est spécifique à chaque processus, il vaut mieux ne pas spécifier sa valeur globalement, mais changer sa valeur lors de l'éxécution de requêtes importantes. query_cache_limit Ne pas mettre en cache les résultats supérieur à cette valeur. (Défaut : 1MO). query_cache_size Taille de mémoire allouée pour stocker les résultats de requêtes effectuées. Si cette valeur est à 0, le cache de requêtes est désactivé (c'est l'état par défaut). query_cache_type Peut prendre les valeurs suivantes (numériques seulement):
sort_buffer Chaque processus qui a besoin de faire un tri alloue un tampon de cette taille. Augmentez cette valeur pour avoir des "ORDER BY" ou des "GROUP BY" plus rapides. |
||||||||||||
| Index - Retour au sommaire tutoriels |
Vos questions techniques : forum d'entraide SGBD & SQL - Publiez vos articles, tutoriels et cours
et rejoignez-nous dans l'équipe de rédaction du club d'entraide des développeurs francophones
Nous contacter - Hébergement - Participez - Copyright © 2000-2009 www.developpez.com - Legal informations.
et rejoignez-nous dans l'équipe de rédaction du club d'entraide des développeurs francophones
Nous contacter - Hébergement - Participez - Copyright © 2000-2009 www.developpez.com - Legal informations.