Şu anki sunucu:
Dosyaları buraya bırakın

SQL gönderme ( 0 ) x -

Sayfa ile ilgili ayarlar Sayfanın en üstüne kaydırmak için çubuğa tklayın
Sorguyu çalıştırmak için Ctrl+Enter tuşlarına basın Sorguyu çalıştırmak için Enter tuşuna basın
küçükten büyüğe
büyükten küçüğe
Sıra:
SQL Hata Ayıklama
Sayı
Çalıştırma sırası
Aldığı süre
Sıralama:
Sorguları grupla
Sorguların grubunu kaldır
Daralt Genişlet İzi göster İzi gizle Sayı: Aldığı süre:
Yer işaretleri
Yenile
Ekle
Yer işaretleri yok
Yer işareti ekle
Seçenekler
Varsayılan değerlere geri yükle
Daralt Genişlet Yeniden sorgula Düzenle Açıkla Profil çıkarma Yer işareti Sorgu başarısız oldu Database: Sorgu süresi:

Danışman sistemi

Olası performans sorunları

Sorun:
Bir günden az çalışma süresi, performans ayarlaması doğru olmayabilir.
Öneri:
Daha fazla doğru ortalamalara sahip olmak için bu çözümleyiciyi çalıştırmadan önce sunucunun bir günden daha uzun çalışmasına izin verilmesi önerilir
Gerekçe:
Çalışma süresi sadece 0 gün, 8 saat, 50 dakika ve 37 saniye
Kullanılan değişken / formül:
Uptime
Deneme:
value < 86400
Sorun:
long_query_time 10 saniyeye ya da daha fazlasına ayarlı, bu nedenle sadece yavaş sorguların günlüklenmesi 10 saniyenin üzerinde bir zaman alır.
Öneri:
Ortamınıza bağlı olarak long_query_time değerinin daha düşük bir değere ayarlanması önerilir. Genellikle 1-5 saniye değeri önerilir.
Gerekçe:
long_query_time şimdilik 10s'ye ayarlı.
Kullanılan değişken / formül:
long_query_time
Deneme:
value >= 10
Sorun:
Yavaş sorgu günlüğü etkisizleştirildi.
Öneri:
slow_query_log ayarını 'ON' yaparak yavaş sorgu günlüklemeyi etkinleştirin. Bu, kötü bir şekilde yürütülen sorguların sorunlarını gidermede yardımcı olacaktır.
Gerekçe:
slow_query_log 'OFF' olarak ayarlı
Kullanılan değişken / formül:
slow_query_log
Deneme:
value == 'OFF'
Sorun:
Birçok sıralanmış satır var.
Öneri:
Satır sıralamanın yüksek miktarıyla hiçbir sorun yokken, ORDER BY yan tümcesinde indekslenmiş sütunları kullanan çok fazla sıralama gerektiren sorgulardan emin olmak isteyebilirsiniz, ki bu çok daha hızlı sıralamayla sonuçlanacaktır.
Gerekçe:
Sıralanmış satır ortalaması: 2.94 saniye başına
Kullanılan değişken / formül:
Sort_rows / Uptime
Deneme:
value * 60 >= 1
Sorun:
İndeksler olmaksızın çok fazla birleştirme var.
Öneri:
Bu, birleştirmeler tam tablo taraması yapıyor anlamına gelir. Birleştirme şartlarında kullanılan sütunlar için indekslerin eklenmesi tablo birleştirmelerini fazlasıyla hızlandıracaktır.
Gerekçe:
Tablo birleştirmeleri ortalaması: 3.18 saniye başına, bu değer saat başına 1'den az olmalıdır
Kullanılan değişken / formül:
(Select_range_check + Select_scan + Select_full_join) / Uptime
Deneme:
value * 60 * 60 > 1
Sorun:
Okunan ilk indeks girişi oranı yüksek.
Öneri:
Bu genellikle sık görülen indeks taramasını gösterir. Eğer bu tablolar UPDATE'lerin ve DELETE'lerin yüksek birimlerine sahip ise ya da sahip olmuşsa, tam indeks taramaları tablo taramalarından daha hızlıdır ama büyük tablolarda çok İşlemci döngüsü gerektirir, çalıştırılan 'OPTIMIZE TABLE' tam indeks taramalarının hızını ve/veya miktarını azaltabilir. Diğer taraftan tam indeks taramaları sadece yeniden yazılan sorgular tarafından azaltılabilir.
Gerekçe:
İndeks taramaları ortalaması: 8.58 dakika başına, bu değer saat başına 1'den az olmalıdır
Kullanılan değişken / formül:
Handler_read_first / Uptime
Deneme:
value * 60 * 60 > 1
Sorun:
Sabit konumdan okunan veri oranı yüksek.
Öneri:
Bu çoğu sorgunun sonuçları sıralaması ve/veya tam tablo taraması yapması gerektiğini gösterir, indeksleri kullanmayan birleştirme sorgular da dahil. Uygulanabilir yerlere indeksleri ekler.
Gerekçe:
Okunan sabit konum oranı ortalaması: 2.92 saniye başına, bu değer saat başına 1'den az olmalıdır
Kullanılan değişken / formül:
Handler_read_rnd / Uptime
Deneme:
value * 60 * 60 > 1
Sorun:
Sonraki tablo satırını okuma oranı yüksek.
Öneri:
Bu çoğu sorgunun tam tablo taraması yaptığını gösterir. Uygulanabilir yerlere indeksleri ekler.
Gerekçe:
Okunan sonraki tablo satırı oranı: 112.2 saniye başına, bu değer saat başına 1'den az olmalıdır
Kullanılan değişken / formül:
Handler_read_rnd_next / Uptime
Deneme:
value * 60 * 60 > 1
Sorun:
Birçok geçici tablo bellekte tutulmak yerine diske yazılıyor.
Öneri:
max_heap_table_size ve tmp_table_size arttırmak yardımcı olabilir. Ancak bazı geçici tablolar her zaman bu değişkenlerin değerinden bağımsız, diske yazılmış olur. MySQL Belgeleri içinde bahsedildiği gibi şu şartlardan (Geçici tablonun içerisinde: BLOB veya TEXT sütununun varlığı ya da 512 bayttan büyük sütunun varlığı) kaçınmak için bunları elemek bakımından sorgularınızı yeniden yazmak zorunda kalacaksınız
Gerekçe:
Diske yazılan geçici tabloların oranı: 14.48 dakika başına, bu değer saat başına 1'den az olmalıdır
Kullanılan değişken / formül:
Created_tmp_disk_tables / Uptime
Deneme:
value * 60 * 60 > 1
Sorun:
Kullanılan MyISAM anahtar arabelleği (indeks önbelleği) % düşük.
Öneri:
key_buffer_size boyutunu azaltmanız gerekebilir, eğer indeksler kaldırılmışsa, görmek için tablolarınızı yeniden gözden geçirin ya da kullanılan indekslerle ilgili beklentileri ve sorguları gözden geçirin.
Gerekçe:
şimdiye kadar kullanılan en fazla % MyISAM anahtar arabelleği: %0, bu değer %95'in üzerinde olmalıdır
Kullanılan değişken / formül:
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
Deneme:
value < 95
Sorun:
Açılan tabloların oranı yüksek.
Öneri:
Açılan tablolar pahalı disk G/Ç gerektirir. table_open_cache değerini arttırmak bunu önleyebilir.
Gerekçe:
Açık tablo oranı: 15.94 saat başına, bu değer saat başına 10'dan az olmalıdır
Kullanılan değişken / formül:
Opened_tables / Uptime
Deneme:
value*60*60 > 10
Sorun:
Açılan dosyaların oranı yüksek.
Öneri:
open_files_limit artışını dikkate alın ve open_files_limit değerini değiştirdikten sonra yeniden başlatıldığında hata günlüğünü denetleyin.
Gerekçe:
Açık dosya oranı: 8.71 saat başına, bu değer saat başına 5'ten az olmalıdır
Kullanılan değişken / formül:
Open_files / Uptime
Deneme:
value * 60 * 60 > 5
Sorun:
Sorgu önbelleğinin %80'den azı değerlendirilmekte.
Öneri:
Buna query_cache_limit çok düşük olması sebep oluyor olabilir. Sorgu önbelleğinin temizlenmesi de yardımcı olabilir.
Gerekçe:
Boş sorgu önbellek belleğinin, toplam sorgu önbelleği boyutuna şu anki oranı %14. Bu %80'in üzerinde olmalıdır
Kullanılan değişken / formül:
100 - Qcache_free_memory / query_cache_size * 100
Deneme:
value < 80
Sorun:
Sorgu önbelleğinde sonuç grubunun en fazla boyutu varsayılanı 1 MiB'tır.
Öneri:
query_cache_limit değiştirmek (genelde artarak) verimi arttırabilir. Bu değişken en fazla boyutu belirler sorgu sonucu sorgu önbelleği içine eklenebilmek zorundadır. Eğer 1 MiB'ın üstünde iyi önbelleklenebilir (çok okuma, az yazma) birçok sorgu sonucu varsa ondan sonra query_cache_limit arttırmak etkiyi arttıracaktır. Halbuki çoğu sonucun iyi önbelleklenemeyen (tablo güncellemelerinden dolayı sıkça geçersiz kılınan) 1 MiB'ın üzerinde olması durumunda query_cache_limit arttırmak verimi azaltacaktır.
Gerekçe:
query_cache_limit 1 MiB'a ayarlı
Kullanılan değişken / formül:
query_cache_limit
Deneme:
value == 1024*1024