Powolne zapytania MYSQL w "dzienniku powolnych zapytań" - ale te same zapytania działają bardzo szybko ręcznie

jako tytułowe, w mojej bazie danych pojawiają się różne zapytania w dzienniku powolnych zapytań, ale kiedy uruchamiam je ręcznie, działają one 10 razy szybciej.Powolne zapytania MYSQL w "dzienniku powolnych zapytań" - ale te same zapytania działają bardzo szybko ręcznie

Na przykład względnie prosta kwerenda wyboru z kilkoma kolejnością params zajmuje często do 100 sekund w dzienniku (tak tabela jest bardzo duża) ... ale kiedy uruchomię ją samodzielnie na tym samym DB trwa to 2 sekundy .

Sprawdziłem wydajność serwera i wydaje się, że nie ma w tym czasie szczególnego spowolnienia ani wąskiego gardła, a wiele zapytań nie zajmuje dużo czasu w tym okresie, ale tylko jeden.

Jak mogę zacząć analizować taki problem?

dzięki za pomoc

Źródło

2012-04-30 Miki Bergin

Zacznę od opublikowania jednego z takich zapytań tutaj, aby uzyskać pomoc w analizowaniu go wraz z "WYBOREM WYBORU ...", aby pokazać, co silnik chce zrobić dla swojej ścieżki wykonania zapytania. – DRapp

Zwykle, jeśli zapytanie zajmuje 1 lub więcej sekund, jest przechwytywane przez wolny dziennik zapytań. 2 sekundy to z pewnością więcej niż 1 sekunda. –

Wild guess: zapytanie jest szybkie, gdy uruchamia się je ręcznie, ponieważ wyniki były buforowane podczas pierwszego wykonania zapytania. Aby to sprawdzić, wyczyść wszystkie pamięci podręczne, a następnie spróbuj ponownie wykonać to samo zapytanie - zajmie to 100 sekund. – nikhil500

system może być bardziej zajęty, gdy zapytanie wykraczająca wszedł powoli dziennik.

Wolny dziennik może wskazywać, że indeksy nie są w pełni wykorzystywane, jeśli wartość argument_wyjości jest większa niż zestaw wyników. Dlatego czas wykonania powinien być uważany za wskazówkę, że zapytanie ma problem, ale polecenie rows_examined da ci bardziej ostateczną odpowiedź.

Czas kwerendy to mierny pomiar wydajności na serwerze z dużym obciążeniem, ponieważ każde zapytanie może być wolne na obciążonym serwerze. Należy użyć EXPLAIN i SHOW PROFILE, aby profilować zapytania i ulepszać je, aby nie obciążały zbytnio serwera.

Podczas profilowania zapytań należy używać SELECT SQL_NO_CACHE ..., aby wyniki nie były przechowywane w pamięci podręcznej zapytań, w przeciwnym razie kolejne wykonanie tej samej kwerendy może korzystać z pamięci podręcznej zapytań, pochylając każdy czas zapytania.

Źródło

2012-04-30 16:12:04

odnośnie do pamięci podręcznej: kiedy ręcznie uruchomiłem zapytanie (nadal na serwerze, nie lokalnie, na tym samym DB) zmieniłem kolejność niektórych warunków, więc nie będzie w stanie dopasować wyniku do poprzednio uruchomionego zapytania. Uruchomiłem wyjaśnić i pokazuje, że używa niektórych indeksów, ale nie jestem pewien, czy są one poprawne. na liście "możliwych indeksów" było wiele innych indeksów, które nie były używane. –

Zauważyłem też, że liczba skanowanych wierszy znacznie przekracza liczbę faktycznie pobranych wierszy. w rzeczywistości samo zdanie ma LIMIT 50, a wiersze zeskanowane to około 3000. Myślałem, że to spowodowane ORDER BY w wyciągu, który według mojego rozumowania pobiera wszystkie wiersze (nawet jeśli w zapytaniu jest LIMIT) i tylko po tym, jak zlecenie przez niego zwraca 50. Czy to jest poprawne? –

@MikiBergin, jeśli klauzula ORDER BY może być obsługiwana przez indeks, to niekoniecznie musi pobrać wszystkie wiersze. Są pewne zastrzeżenia, ale tutaj jest zbyt wiele do omówienia. Polecam, jeśli potrzebujesz pomocy w optymalizacji konkretnego zapytania, opublikuj osobne pytanie wraz z całym zapytaniem, odpowiednim schematem oraz wynikami EXPLAIN i SHOW PROFILE. –

Powolne zapytania MYSQL w "dzienniku powolnych zapytań" - ale te same zapytania działają bardzo szybko ręcznie

Odpowiedz

Powiązane problemy