FAQ MySQLConsultez toutes les FAQ

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).

• 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.
  

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

EXPLAIN SELECT * FROM ma_table

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.
  

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.

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.

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

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.

En utilisant cette commande :

SHOW VARIABLES LIKE '%_cache_%';

En utilisant cette commande :

SHOW VARIABLES LIKE '%_buffer_%';