La mauvaise nouvelle :il existe des outils d'interface graphique pour vous aider, mais c'est un travail qualifié et de grande envergure. Donc, ils ne couvrent pas tout, il est probable que vous deviez utiliser des instructions de ligne de commande/sql, etc. pour vous aider. Je n'ai vraiment utilisé que les outils de ligne de commande. Je vais donner un aperçu des choses que je connais/ai utilisées :
Tout d'abord, vous avez besoin d'une bonne conception de base de données. Si la conception est mauvaise, vous ne pouvez pas aller plus loin. Cela inclut la normalisation, ainsi que l'utilisation de types appropriés pour les champs. Je vais laisser ce point ici, car je pense que c'est un peu un aparté, et pas ce que vous recherchez.
Assurez-vous que le cache de requêtes MySQL est configuré et fonctionne et donnez-lui un peu plus de RAM si vous le pouvez, et assurez-vous que vos requêtes importantes ne font rien qui empêche mysql de les mettre en cache. Par exemple, l'utilisation de la fonction NOW() dans les requêtes fait cela - pour des raisons évidentes - NOW change toutes les secondes ! Vous pouvez à la place mettre un horodatage dans sql et utiliser l'heure à la minute/heure/jour la plus proche (la période la plus longue avec laquelle vous pouvez vous en sortir) pour permettre à mysql d'obtenir des avantages de mise en cache.
Pour commencer à optimiser les choses :Coller "EXPLAIN" devant select est LE moyen de voir comment une requête est exécutée et d'identifier comment l'améliorer. Apprenez à interpréter la sortie :http://dev.mysql .com/doc/refman/5.0/en/using-explain.html Vous pourrez souvent ajouter de nouveaux index/ajouter des colonnes à ceux existants pour améliorer les choses. Mais vous rencontrerez également des moments où les requêtes doivent être restructurées.
Commencer à améliorer les performances avec MySQL (en supposant que vous ne savez pas déjà quelle est la requête problématique) consiste à vérifier le journal des requêtes lentes - il enregistre dans un fichier toutes les requêtes prenant plus de x secondes.
La vue d'ensemble, y compris la configuration pour s'il n'est pas déjà enregistré, est ici :http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html - J'ai également trouvé que définir long_query_time sur 0 pendant environ un jour, afin que toutes les requêtes soient enregistrées ici avec le temps pris, est un moyen utile d'avoir une idée exacte de la direction que prennent les performances. Mais je n'irais pas là-bas tout de suite ! Et ne le laissez pas allumé, les journaux peuvent devenir volumineux.
Une fois que vous avez quelques jours de journalisation, j'ai trouvé mysqlsla (analyseur de journal lent mysql) à partir d'ici :http ://hackmysql.com/mysqlsla est un bon outil.
Il peut faire plus que ralentir l'analyse du journal des requêtes - lisez le manuel. Mais pour expliquer ce qu'il fait pour les journaux lents :le journal des requêtes lentes peut contenir beaucoup de données, il peut donc être difficile de déterminer quelles requêtes sont globalement les plus coûteuses ; par exemple :tenez compte du nombre d'exécutions et du moment où deux requêtes sont en fait identiques avec un identifiant différent dans une clause where.
MySQL sla fait tout cela pour vous. Il parcourt le journal et peut regrouper des requêtes qui sont identiques/ont des valeurs différentes dans les clauses where. Il vous présente ensuite (par défaut) les 10 requêtes les plus importantes en termes de temps d'exécution total - ce qui réserve souvent des surprises, mais est généralement le point de départ le plus productif - prenez la requête la plus coûteuse et utilisez EXPLAIN dessus et voyez si vous pouvez l'améliorer il.
Certaines requêtes prennent beaucoup de temps et ne peuvent pas être facilement améliorées. Dans ce cas, pouvez-vous obtenir les données d'une autre manière ou au moins les mettre en cache à la place ? Vous pouvez même constater que la modification du schéma de base de données est nécessaire. De même, certaines requêtes peuvent être en haut de la sortie mysqlsla parce que vous les exécutez beaucoup (surtout vrai si long_query_time est défini sur 0), même si elles s'exécutent assez rapidement. Il est peut-être temps d'ajouter une mise en cache à votre application ?
http://www.maatkit.org/ semble également prometteur - je ne l'ai jamais utilisé, mais l'outil mk-query-profiler devrait être utile pour mieux comprendre pourquoi les requêtes sont lentes.
Une chose complètement distincte à regarder également :la page "statut" dans PHPMYADMIN (ou vous pouvez exécuter toutes les requêtes pour générer cette information ....) - elle met en évidence les choses qu'elle pense être mauvaises en rouge, et peut vous aider voir où vous pourriez tirer profit de l'allocation des ressources système. Je ne sais pas grand-chose à ce sujet - mon approche a toujours été que si quelque chose est rouge et semble mauvais, aller lire à ce sujet et décider si c'est important et si je dois faire quelque chose (cela signifie généralement allouer plus de ressources à MySQL en modifiant la configuration).
Récemment, j'ai découvert que l'exécution de SHOW PROCESSLIST peut également être utile sur un serveur qui souffre. Bien qu'il ne vous donne que des informations en direct (enfin, un instantané en direct), il peut vous aider à avoir une idée de ce qui se passe à un moment donné, surtout si vous actualisez plusieurs fois et observez les changements. J'ai récemment repéré un serveur utilisant chaque connexion mysql disponible pour exécuter une requête identique en utilisant cette méthode. Bien sûr, cela aurait été dans le journal des requêtes lentes, mais c'était un moyen vraiment rapide et évident de voir ce qui se passait.
