Réglage des paramètres du serveur
<<<
Contrôle des performances de l'optimisateur de requêtes Influences de la compilation et des liaisons sur la vitesse de MySQL
>>>

7.5 Optimiser le serveur MySQL
7 Optimisation de MySQL
 Manuel de Référence MySQL 4.1 : Version Française

Réglage du système, au moment de la compilation, et paramètres du démarrage
Réglage des paramètres du serveur
->Contrôle des performances de l'optimisateur de requêtes
Influences de la compilation et des liaisons sur la vitesse de MySQL
Comment MySQL gère la mémoire
Comment MySQL utilise le DNS

7.5.3 Contrôle des performances de l'optimisateur de requêtes

La tâche de l'optimisateur de requête est de trouver une méthode optimale pour exécuter une requête SQL. Comme la différence entre de ``bonnes'' et de ``mauvaises'' performances peut être de plusieurs grandeur d'ordre, la plupart des optimisateurs de requêtes, y compris celui de MySQL, fait une recherche plus ou moins exhaustive des méthodes possibles pour traiter une requête. Pour les jointures, le nombre de méthodes croit exponentiellement avec le nombre de tables. Pour les petits nombres de tables (jusqu'à 7 ou 10), ce n'est pas sensible. Mais dès que de grosses requêtes sont soumises, le temps passé à l'optimisation peut être source de ralentissement pour le serveur.

MySQL 5.0.1 propose une nouvelle méthode plus souple pour l'optimisation, qui permet à l'utilisateur de contrôler l'exhaustivité de la recherche de l'optimisateur dans sa quête pour la méthode la plus efficace pour traiter une requête. L'idée générale est que plus le nombre de méthodes étudiées est petit, moins l'optimisateur prendra de temps à compiler la requête. D'un autre coté, comme l'optimisateur a omis certaines méthodes, il peut avoir mis de coté la méthode optimale.

Le comportement de l'optimisateur peut être contrôlé grâce à deux variables système :

  • La variable optimizer_prune_level indique à l'optimisateur d'omettre des méthodes basées sur l'estimation du nombre de lignes utilisées dans les tables. Notre expérience montre que ce type de ``prévision'' échoue rarement, tout en réduisant considérablement le temps de compilation des requêtes. C'est pour cela que cette variable est active par défaut ( optimizer_prune_level =1). Cependant, si vous pensez que l'optimisateur pourrait trouver mieux, alors cette option peut être désactivée ( optimizer_prune_level =0), au risque de voir la compilation de la requête prendre beaucoup plus de temps. Notez que même si vous utilisez cette heuristique, l'optimisateur va étudier un nombre exponentiel de méthodes.
  • La variable optimizer_search_depth indique la ``profondeur'' d'analyse de l'optimisateur. Les valeurs les plus faibles de optimizer_search_depth peuvent conduire à de grandes différences dans le temps de compilation. Par exemple, une requête avec 12-13 ou plus peut facilement prendre des heures ou des jours à compiler si optimizer_search_depth a une valeur proche du nombre de tables à traiter. Mais, si optimizer_search_depth vaut 3 ou 4, le compilateur peut traiter cette requête en une minute environ. Si vous n'êtes pas sûrs de la valeur raisonnable de optimizer_search_depth , donnez lui la valeur de 0 pour que l'optimisateur puisse déterminer la valeur automatiquement.

<< Contrôle des performances de l'optimisateur de requêtes >>
Réglage des paramètres du serveur Optimiser le serveur MySQL Influences de la compilation et des liaisons sur la vitesse de MySQL