Tutaj upuść pliki

Przesyłanie SQL ( 0 ) x -

Ustawienia strony Kliknij na pasku, aby przewinąć do góry strony
Wciśnij Ctrl+Enter aby wykonać zapytanie Wciśnij Enter, aby wykonać zapytanie
rosnąco
malejąco
Kolejność:
Debug SQL
Licznik
Kolejność wykonywania
Zajęło czasu
Sortuj według:
Grupuj kwerendy
Rozgrupuj kwerendy
Zwiń Rozszerz Pokaż ścieżkę Ukryj ścieżkę Liczba: Zajęło to:
Zakładki
Odśwież
Dodaj
Brak zakładek
Dodaj zakładkę
Opcje
Przywróć wartości domyślne
Zwiń Rozszerz Wykonaj zapytanie ponownie Edytuj Wyjaśnij Profilowanie Dodaj do zakładek Zapytanie nie powiodło się Baza danych: Czas zapytania:

Doradca systemu

Możliwe problemy z wydajnością

Wydanie:
Czas działania poniżej 1 dnia, optymalizacja wydajności może być niedokładna.
Rekomendacja:
Aby mieć dokładniejsze średnie zalecane jest, aby pozwolić serwerowi działać przez conajmniej jeden dzień przed uruchomieniem tego analizatora
Uzasadnienie:
Czas działania to tylko 0 dni, 0 godzin, 16 minut i 57 sekund
Użyta zmienna/formuła:
Uptime
Testuj:
value < 86400
Wydanie:
long_query_time jest ustawiony na 10 sekund lub więcej, dlatego rejestrowane są tylko te powolne zapytania, które trwają powyżej 10 sekund.
Rekomendacja:
Sugeruje się, aby ustawić long_query_time na niższą wartość, w zależności od Twojego środowiska. Najczęściej sugerowaną wartością jest 1-5 sekund.
Uzasadnienie:
long_query_time jest aktualnie ustawiony na 10s.
Użyta zmienna/formuła:
long_query_time
Testuj:
value >= 10
Wydanie:
Rejestrowanie powolnych zapytań jest wyłączone.
Rekomendacja:
Włącz rejestrowanie powolnych zapytań ustawiając slow_query_log na 'ON'. Pomoże to w rozwiązywaniu problemów z powoli wykonującymi się zapytaniami.
Uzasadnienie:
slow_query_log jest ustawiony na 'OFF'
Użyta zmienna/formuła:
slow_query_log
Testuj:
value == 'OFF'
Wydanie:
Jest wiele wierszy, które są sortowane.
Rekomendacja:
Chociaż nie ma nic złego w dużej ilości sortowania wierszy, możesz chcieć upewnić się, że zapytania, które wymagają dużo sortowania, używają indeksowanych kolumn w klauzuli ORDER BY, ponieważ spowoduje to znacznie szybsze sortowanie.
Uzasadnienie:
Sortuj średnie wiersze: 5.18 na sekundę
Użyta zmienna/formuła:
Sort_rows / Uptime
Testuj:
value * 60 >= 1
Wydanie:
Istnieje zbyt wiele łączy bez indeksów.
Rekomendacja:
Oznacza to, że łączenia wykonują pełne skanowanie tabeli. Dodanie indeksów dla kolumn używanych w warunkach łączenia znacznie przyspieszy dołączanie tabel.
Uzasadnienie:
Tabela dołącza średnią: 9.9 na sekundę, wartość ta powinna być mniejsza niż 1 na godzinę
Użyta zmienna/formuła:
(Select_range_check + Select_scan + Select_full_join) / Uptime
Testuj:
value * 60 * 60 > 1
Wydanie:
Wskaźnik odczytania pierwszego wpisu indeksu jest wysoki.
Rekomendacja:
Zwykle oznacza to częste pełne skanowanie indeksu. Pełne skanowanie indeksu jest szybsze niż skanowanie tabeli, ale wymaga wiele cykli procesora w dużych tabelach, jeśli te tabele, które mają lub miały duże ilości aktualizacji i kasowania, uruchomiono 'OPTIMIZE TABLE" może zmniejszyć ilość i/lub przyspieszyć pełne skanowanie indeksu. Innych niż tego pełnego skanowania indeksu może zostać obniżona o przepisanie zapytania.
Uzasadnienie:
Indeks skanuje średnią: 26.55 na minutę, wartość ta powinna być mniejsza niż 1 na godzinę
Użyta zmienna/formuła:
Handler_read_first / Uptime
Testuj:
value * 60 * 60 > 1
Wydanie:
Tempo odczytu danych z ustalonej pozycji jest wysokie.
Rekomendacja:
Oznacza to, że wiele zapytań potrzebują wyników sortowania i/lub wykonać pełny skan tabeli, w tym połączyć pytania które nie korzystają z indeksów. Dodaj indeksy w stosownych przypadkach.
Uzasadnienie:
Stawka odczytu stałej średniej pozycji: 5.18 na sekundę, wartość ta powinna być mniejsza niż 1 na godzinę
Użyta zmienna/formuła:
Handler_read_rnd / Uptime
Testuj:
value * 60 * 60 > 1
Wydanie:
Tempo odczytu kolejnego wiersza tabeli jest wysokie.
Rekomendacja:
Oznacza to, że wiele zapytań robi pełne skanowanie tabeli. Dodaj indeksy w stosownych przypadkach.
Uzasadnienie:
Stawka odczytu następnego wiersza tabeli: 270.68 na sekundę, wartość ta powinna być mniejsza niż 1 na godzinę
Użyta zmienna/formuła:
Handler_read_rnd_next / Uptime
Testuj:
value * 60 * 60 > 1
Wydanie:
Wiele tabel tymczasowych są zapisywane na dysku zamiast przechowywania w pamięci.
Rekomendacja:
Zwiększenie max_heap_table_size i tmp_table_size może pomóc. Jednak niektóre tabele tymczasowe zawsze są zapisywane na dysku, niezależnie od wartości tych zmiennych. Aby wyeliminować te trzeba będzie przepisać zapytania, aby uniknąć tych warunków (w obrębie tabeli tymczasowej: Obecność kolumny BLOB lub TEXT lub obecności kolumny większej niż 512 bajtów) Jak wspomniano w Dokumentacji MySQL
Uzasadnienie:
Stawka tabel tymczasowych zapisywanych na dysku: 1.07 na sekundę, wartość ta powinna być mniejsza niż 1 na godzinę
Użyta zmienna/formuła:
Created_tmp_disk_tables / Uptime
Testuj:
value * 60 * 60 > 1
Wydanie:
Bufor klucza MyISAM (pamięć podręczna indeksu) % używanego jest niski.
Rekomendacja:
Być może trzeba zmniejszyć rozmiar key_buffer_size, ponownie przeanalizuje tabele, czy indeksy zostały usunięte, lub zbadać zapytania i oczekiwania dotyczące tego, co indeksy są używane.
Uzasadnienie:
maks % klucz bufora MyISAM używany co: 0%, wartość ta powinna być wyższa niż 95%
Użyta zmienna/formuła:
Key_blocks_used * key_cache_block_size / key_buffer_size * 100
Testuj:
value < 95
Wydanie:
Wskaźnik otwartych tabel jest wysoki.
Rekomendacja:
Otwieranie tabel wymaga dysk I/O, która jest kosztowna. Zwiększenie table_open_cache może tego uniknąć.
Uzasadnienie:
Wskaźnik otwartej tabeli: 7.43 na minutę, wartość ta powinna być mniejsza niż 10 na godzinę
Użyta zmienna/formuła:
Opened_tables / Uptime
Testuj:
value*60*60 > 10
Wydanie:
Wskaźnik otwartych plików jest wysoki.
Rekomendacja:
Rozważ zwiększenie open_files_limit i sprawdź dziennik błędów po restarcie po zmianie open_files_limit.
Uzasadnienie:
Wskaźnik otwartych plików: 3.42 na minutę, wartość ta powinna być mniejsza niż 5 na godzinę
Użyta zmienna/formuła:
Open_files / Uptime
Testuj:
value * 60 * 60 > 5
Wydanie:
Mniej niż 80% z zapytania pamięci podręcznej jest wykorzystywane.
Rekomendacja:
Może to być spowodowane przez query_cache_limit bo jest zbyt niski. Flushing zapytania pamięci podręcznej może pomóc.
Uzasadnienie:
Bieżący stosunek wolnej pamięci podręcznej zapytań do całkowitego rozmiaru pamięci podręcznej zapytań wynosi 4%. Powinien być powyżej 80%
Użyta zmienna/formuła:
100 - Qcache_free_memory / query_cache_size * 100
Testuj:
value < 80
Wydanie:
Maksymalny rozmiar zestawu wyników w pamięci podręcznej zapytania jest domyślnie 1 MB.
Rekomendacja:
Zmiana query_cache_limit (zwykle poprzez zwiększenie) może zwiększać efektywność. Zmienna ta określa maksymalny rozmiar wyniku kwerendy która powinna być wprowadzona do zapytania pamięci podręcznej. Jeśli istnieje wiele wyników kwerendy powyżej 1MB, które są dobrze Cacheable (wiele czyta, mało pisze), a następnie zwiększenie query_cache_limit zwiększy efektywność. O ile w przypadku wielu wyników zapytania będących ponad 1 MB, które nie są bardzo dobrze Cacheable (często unieważnione z powodu aktualizacji tabeli) zwiększanie query_cache_limit może zmniejszyć wydajność.
Uzasadnienie:
query_cache_limit jest ustawiony na 1 MB
Użyta zmienna/formuła:
query_cache_limit
Testuj:
value == 1024*1024