FAQ MySQLConsultez toutes les FAQ

Nombre d'auteurs : 16, nombre de questions : 155, dernière mise à jour : 22 avril 2014  Ajouter une question

 

Cette FAQ a été conçue à partir des questions fréquemment posées sur le forum MySQL de Developpez.com. Elle ne prétend pas à être exhaustive et peut contenir des erreurs occasionnelles. Si vous relevez une coquille, n'hésitez pas à nous le faire savoir.

Pour participer à cette FAQ, veuillez envoyer vos réponses sur le forum.


SommaireAdministrationPerformances (10)
précédent sommaire suivant
 

En général, lorsque vous voulez rendre une recherche (SELECT ... WHERE ... ) plus rapide, la première chose à faire est de voir si vous pouvez ajouter des index (Cf : quand mettre un index sur mon champ).

Autre étape importante, analyser la différence entre le nombres d'écritures (insertion, modification, suppression) et le nombre de lectures. Si vous avez beaucoup plus de lectures que d'écritures (90% des cas), les index sont grandement utiles . Si vous avez beaucoup d'écritures et très peu de lectures (gestion d'un log des connexions à votre application), évitez les index car ils accélèrent certes les recherches, mais il ralentissent les écritures !

Autre point discutable : normalement, vous devriez essayer de garder vos données non redondantes (ce qui s'appelle la troisième forme normale dans les théories de bases de données), mais dans la pratique ne vous empêchez pas de dupliquer des données ou de créer des tables de sommaire, pour gagner de la vitesse.
Par contre assurez-vous d'avoir des outils vérifiant que les données redondantes sont bien identiques (que l'une n'ait pas été modifiée sans l'autre).

Mis à jour le 16 juin 2004 Alexandre T

  • Premier point à noter : un index accélère les recherches et donc les lectures mais ralentit les écritures. Donc une table stockant les connexions à la base peut ne pas avoir d'index.

  • Les champs à indexer sont en général ceux qui sont utilisés dans les recherches (clauses WHERE, ORDER BY ou GROUP BY) et les pivots des jointures.

  • On peut également mentionner que les index fonctionnent mieux sur des champs à valeur UNIQUE car l'accès à la ligne concernée est direct. Plus une colonne peut prendre de valeurs différentes, moins l'index sera efficace.

Mis à jour le 16 juin 2004 Alexandre T

Pour savoir si un index est utilisé, la commande EXPLAIN est nécessaire. Exemple :

Code sql : Sélectionner tout
EXPLAIN SELECT * FROM ma_table
Avec l'aide d'EXPLAIN, vous pouvez identifier les index à ajouter pour accélérer les commandes et ceux à supprimer car ils ne sont pas utilisés.
L'utilisation d'EXPLAIN est expliquée ici : http://dev.mysql.com/doc/mysql/fr/EXPLAIN.html.

Pour réellement optimiser votre application, paramétrez votre serveur pour tracer toutes les requêtes exécutées sur la base. Ouvrez ce log, et pour chaque requête, utilisez EXPLAIN. C'est long, fastidieux mais très rentable.

Mis à jour le 16 juin 2004 Alexandre T

Si l'étape précédente est réalisée, vous pouvez optimiser votre serveur.

  • Premier point à noter en Mysql : plus le système de droits est complexe, plus le serveur est lent.

  • Utilisez OPTIMIZE TABLE de temps à autre, pour éviter la fragmentation lors de l'utilisation de tables avec un format de ligne dynamique.

  • Enfin, si vous êtes maître de votre serveur et de sa configuration, vous pouvez modifier les paramétrages et donc les variables de votre serveur. Par expérience, il y a deux variables intéressantes à modifier en premier : table_cache (taille du cache des tables ouvertes) et key_buffer_size (taille du tampon utilisé pour les index). A partir de MySQL 4.0.1, augmenter la taille du cache de requêtes (query_cache_size) peut également être intéressant.

Lors de la première exécution d'une requête, le SGBD doit lire des données physiquement, puis effectuer des opérations parfois lourdes sur ces données.
Il convient alors de sauvegarder en mémoire vive ces résultats afin de pouvoir les récupérer directement en cas de besoin sans répéter toutes les opérations.
Le gain de temps est colossal et ceci est une part très importante des optimisations faites par les SGBD.
Il est donc important de configurer au mieux ces buffers et caches en fonction du type d'activité du serveur.

Consultez la documentation pour les modifications de ces valeurs : http://dev.mysql.com/doc/mysql/fr/Se...variables.html

Mis à jour le 16 juin 2004 Alexandre T Florian

Normalement, cela ne sert à rien de séparer une table en différentes tables plus petites, juste parce que vous pensez que vos lignes deviennent longues et que cela n'est pas esthétique. En effet, comme le précise la documentation pour accéder à une ligne, le plus long est le temps d'accès au premier octet de la ligne. Après cela, les disques modernes vont lire très rapidement cette ligne, et ce suffisament vite pour la plupart des applications.

Le seul cas où cela peut être important est si vous êtes capable d'extraire une nouvelle table à format de ligne fixe (et non dynamique).
Certains vous diront aussi que si vous avez besoin de scanner régulièrement la table, mais que vous n'avez que très rarement besoin de la plupart des colonnes, alors la table peut être séparée.

Mis à jour le 16 juin 2004 Alexandre T

Lors de la première exécution d'une requête, le SGBD doit lire des données physiquement, puis effectuer des opérations parfois lourdes sur ces données.
Il convient alors de sauvegarder en mémoire vive ces résultats afin de pouvoir les récupérer directement en cas de besoin sans répéter toutes les opérations.

Le gain de temps est colossal et ceci est une part très importante des optimisations faites par les SGBD.
Il est donc important de configurer au mieux ces buffers et caches en fonction du type d'activité du serveur.

Mis à jour le 11 août 2008 Florian

L'unité utilisée est l'octet.

Mis à jour le 11 août 2008 Florian

Non, les définitions de la taille des buffers et caches sont des tailles maximales. Si le SGBD n'a besoin que de 4Mo, seulement 4Mo seront utilisés.

Mis à jour le 11 août 2008 Florian

En utilisant cette commande :

Code sql : Sélectionner tout
SHOW VARIABLES LIKE '%_cache_%';

Mis à jour le 11 août 2008 Florian

En utilisant cette commande :

Code sql : Sélectionner tout
SHOW VARIABLES LIKE '%_buffer_%';

Mis à jour le 11 août 2008 Florian

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire suivant
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2017 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

 
Contacter le responsable de la rubrique MySQL