Déposer des fichiers ici

Téléversement SQL ( 0 ) x -

Paramètres relatifs à la page Cliquer sur la barre pour faire défiler en haut de page
Faire Ctrl+Entrée pour exécuter la requête Faire Entrée pour exécuter la requête
croissant
décroissant
Ordre :
Déboguer SQL
Nombre
Ordre d'exécution
Temps nécessaire
Trier par :
Regrouper les requêtes
Dissocier les groupes
Réduire Développer Afficher le suivi Masquer le suivi Nombre : Temps écoulé :
Signets
Actualiser
Ajouter
Aucun signet
Ajouter un signet
Options
Restore default values
Réduire Développer Exécuter la requête à nouveau Éditer Expliquer Profilage Signet La requête a échoué Base de données: Daté du:

Conseiller

Impact possible sur les performances

Problème :
Le système est en marche depuis moins d'un jour, les conseils de performance peuvent être inexacts.
Recommandation :
Pour obtenir de meilleurs résultats, il est recommandé de laisser le serveur fonctionner plus d'une journée avant de lancer cet analyseur
Alignement :
Le temps de disponibilité n'est que de 0 jour(s), 0 heure(s), 5 minute(s) et 4 seconde(s)
Variable/formule utilisée :
Uptime
Test :
value < 86400
Problème :
La valeur du paramètre long_query_time est de 10 secondes ou plus, donc seules les requêtes lentes prenant plus de 10 secondes sont inscrites au journal.
Recommandation :
Il est suggéré de donner à long_query_time une plus petite valeur, selon l'environnement. Habituellement une valeur entre 1 et 5 secondes fait l'affaire.
Alignement :
long_query_time est actuellement défini à 10 seconde(s).
Variable/formule utilisée :
long_query_time
Test :
value >= 10
Problème :
Le journal des requêtes lentes est désactivé.
Recommandation :
Activer la journalisation des requêtes lentes en réglant slow_query_log à « Activé » (ON). Ceci aidera à dépanner les problèmes de lenteur de requêtes.
Alignement :
slow_query_log est défini à la valeur « Désactivé » (OFF)
Variable/formule utilisée :
slow_query_log
Test :
value == 'OFF'
Problème :
Un grand nombre de lignes sont en train d'être triées.
Recommandation :
Bien qu'un grand nombre de tris ne soit pas mauvais en soi, vérifier que les requêtes qui demandent un tri utilisent des colonnes indexées dans la clause ORDER BY, ce qui va grandement accélérer les tris.
Alignement :
Moyenne des lignes triées : 2.18 par seconde
Variable/formule utilisée :
Sort_rows / Uptime
Test :
value * 60 >= 1
Problème :
Il y a trop de jointures sans index.
Recommandation :
Ceci signifie que les jointures requièrent des lectures de tables au complet. L'ajout d'index sur les colonnes utilisées dans les critères de jointure va accélérer les jointures.
Alignement :
Moyenne de jointures de tables : 4.51 par seconde, cette valeur devrait être moins de 1 par heure
Variable/formule utilisée :
(Select_range_check + Select_scan + Select_full_join) / Uptime
Test :
value * 60 * 60 > 1
Problème :
La fréquence de lecture de la première entrée d'index est élevée.
Recommandation :
Ceci indique habituellement des balayages complets des index. Cette opération est plus rapide qu'un balayage complet de table mais requiert beaucoup d'UCT pour des tables volumineuses. Si ces tables ont eu un grand nombre de UPDATE et DELETE, faire un « OPTIMIZE TABLE » peut améliorer les choses. Sinon, il s'agit de récrire les requêtes.
Alignement :
Moyenne de balayage des index : 11.45 par minute, cette valeur devrait être moins de 1 par heure
Variable/formule utilisée :
Handler_read_first / Uptime
Test :
value * 60 * 60 > 1
Problème :
La fréquence de lecture de données à partir d'une position fixe est élevée.
Recommandation :
Ceci indique que plusieurs requêtes doivent effectuer un tri et/ou un balayage complet de table, incluant des jointures qui n'utilisent pas d'index. Ajouter des index si possible.
Alignement :
Fréquence de lecture d'une position fixe : 2.18 par seconde, devrait être de moins de 1 par heure
Variable/formule utilisée :
Handler_read_rnd / Uptime
Test :
value * 60 * 60 > 1
Problème :
La fréquence de lecture de la prochaine ligne dans la table est élevée.
Recommandation :
Ceci indique que plusieurs requêtes doivent effectuer un balayage complet de table. Ajouter des index si possible.
Alignement :
Fréquence de lecture de la prochaine ligne de table : 197.85 par seconde, devrait être de moins de 1 par heure
Variable/formule utilisée :
Handler_read_rnd_next / Uptime
Test :
value * 60 * 60 > 1
Problème :
Plusieurs tables temporaires sont écrites sur disque au lieu d'être conservées en mémoire.
Recommandation :
Augmenter max_heap_table_size et tmp_table_size pourrait aider. Cependant il y a toujours quelques tables temporaires qui sont écrites sur disque, peu importe la valeur de ces variables. Pour éliminer ces tables temporaires, il faut modifier les requêtes pour éviter ces conditions (dans une table temporaire : présence d'une colonne BLOB ou TEXT ou d'une colonne de taille supérieure à 512 octets) tel que décrit dans la documentation MySQL
Alignement :
Taux de tables temporaires écrites sur disque : 16.97 par minute, cette valeur devrait être moins de 1 par heure
Variable/formule utilisée :
Created_tmp_disk_tables / Uptime
Test :
value * 60 * 60 > 1
Problème :
Le % de la mémoire tampon utilisé pour les clés MyISAM est faible.
Recommandation :
Il faudrait considérer la diminution de la taille de key_buffer_size, examiner les table pour voir si les index ont été enlevés, ou examiner les requêtes pour voir quels index sont utilisés.
Alignement :
Le % maximum de mémoire tampon pour les clés MyISAM utilisé est de 0%, cette valeur devrait dépasser 95%
Variable/formule utilisée :
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
Test :
value < 95
Problème :
Le % des index qui utilisent la mémoire tampon MySQL est faible.
Recommandation :
Il faudrait considérer l'augmentation de key_buffer_size.
Alignement :
Index lus depuis la mémoire : 90%, cette valeur devrait être au-dessus de 95%
Variable/formule utilisée :
100 - (Key_reads / Key_read_requests * 100)
Test :
value < 95
Problème :
La fréquence d'ouverture de tables est élevée.
Recommandation :
Ouvrir des tables requiert des accès au disque, ce qui est coûteux. Augmenter table_open_cache pourrait remédier à la situation.
Alignement :
Fréquence d'ouverture des tables : 9.08 par minute, cette valeur ne devrait pas dépasser 10 par heure
Variable/formule utilisée :
Opened_tables / Uptime
Test :
value*60*60 > 10
Problème :
La fréquence d'ouverture de fichiers est élevée.
Recommandation :
Considérer l'augmentation de open_files_limit, et vérifier le journal des erreurs après avoir redémarré.
Alignement :
Fréquence d'ouverture de fichiers : 7.5 par minute, cette valeur devrait être moins de 5 à l'heure
Variable/formule utilisée :
Open_files / Uptime
Test :
value * 60 * 60 > 5
Problème :
Moins de 80% du cache de requêtes est utilisé.
Recommandation :
Ceci peut être causé par une trop faible valeur de query_cache_limit. Initialiser le cache des requêtes pourrait également aider.
Alignement :
Le ratio actuel de mémoire libre pour le cache de requêtes par rapport à la mémoire totale du cache est de 1%. Il devrait se situer à plus de 80%
Variable/formule utilisée :
100 - Qcache_free_memory / query_cache_size * 100
Test :
value < 80
Problème :
La taille maximale d'un jeu de résultats dans le cache de requêtes est la valeur par défaut de 1 Mio.
Recommandation :
Augmenter query_cache_limit peut améliorer l'efficacité. Cette variable détermine la taille maximale qu'un résultat doit avoir pour être inséré dans le cache de requêtes. S'il existe plusieurs résultats d'une taille supérieure à 1 Mio qui peuvent être mis en cache (grand nombre de lectures, peu d'écritures), alors une augmentation de query_cache_limit va aider. Dans le cas contraire, cette augmentation va réduire l'efficacité.
Alignement :
query_cache_limit a une valeur de 1 Mio
Variable/formule utilisée :
query_cache_limit
Test :
value == 1024*1024