Uaktualniliśmy do MySQL 5.6 i zaczęliśmy zauważać znaczny wzrost obciążenia serwera db, i wreszcie dowiedzieliśmy się, że query_cache_typedomyślnie domyślnie ustawiony jest na start od 5.6.
Włączyliśmy go ponownie i widzimy zmniejszenie ładowania, dlaczego ta wartość jest domyślnie wyłączona, zaczynamy od MySQL 5.6? Nie widzę problemu z włączoną obsługą.
Odpowiedzi:
Potrzebujesz historii InnoDB, aby zrozumieć dlaczego. Oto jest:
InnoDB i pamięć podręczna zapytań są w stanie ciągłej wojny. InnoDB jest bardzo obciążony podczas sprawdzania zmian w puli buforów InnoDB, a następnie sprawdzania pamięci podręcznej zapytań pod kątem tych samych zmian.
Przed MySQL 5.0 pamięć podręczna zapytań była wyłączona dla InnoDB. Teraz InnoDB współdziała z nim. Aby uprościć sprawy, możesz po prostu wyłączyć pamięć podręczną zapytań, ustawiając rozmiar_danych_pytania na 0.
Zgodnie z dokumentacją MySQL na zapytanie_czas_buforu
Jeśli serwer jest uruchamiany z typem zapytania_cache_pracy ustawionym na 0, w ogóle nie uzyskuje muteksu pamięci podręcznej zapytań, co oznacza, że buforowania zapytań nie można włączyć w czasie wykonywania, a wykonywanie zapytania jest zmniejszone.
Ustawienie parametru query_cache_size na 0 nie jest rozwiązaniem uniwersalnym.
Przyczyną wojny są przede wszystkim koszty ogólne. InnoDB zawsze sprawdza zmiany. Większa pamięć podręczna zapytań sprawi, że InnoDB będzie działać znacznie ciężej. Wyłączając pamięć podręczną zapytań, niech InnoDB i pamięć podręczna zapytań będą szczęśliwe. Jednak Ty (Deweloper / DBA) możesz być ofiarą tej wojny z powodu złej wydajności zapytań, nawet przy takim traktacie pokojowym.
W zależności od poniższych
powinieneś ustawić query_cache_size na dowolną liczbę, która Twoim zdaniem zwiększa wydajność (Jest to równoznaczne z rozpoczęciem podziemnego ruchu).
Jeśli zastanawiasz się, gdzie wymyśliłem tę historię wojenną, zobacz mój stary post
Sep 05, 2012: Czy koszty związane z częstym unieważnianiem pamięci podręcznej zapytań są tego warte?Przeczytaj go uważnie, ponieważ nauczyłem się tego na stronach 209-215 High Performance MySQL (wydanie drugie)
Zalecałem wcześniej wyłączenie pamięci podręcznej zapytań innym osobom
Sep 25, 2013: unieważnianie wpisów w pamięci podręcznej zapytań (klucz)Sep 26, 2013: wartość trafienia w pamięci podręcznej zapytań nie zmienia się w mojej bazie danychDec 23, 2013: MySQL z dużym zużyciem procesora i pamięciUWAGA: Zdaję sobie sprawę, że pytanie dotyczyło typu query_cache_type . Ma to wpływ na pamięć podręczną zapytań. Wyłączenie pamięci podręcznej powoduje, że dominuje nad nią InnoDB. Ręczne ustawienie typu query_cache_cpe zmusza programistę / DBA do dokładnego przemyślenia rodzaju zapytań, jakie napotka bufor podręczny.
Mam wpis na blogu wyjaśniający, dlaczego to tutaj jest .
Wersja skrócona: pamięć podręczna zapytań powoduje problemy ze skalowalnością na komputerach wielordzeniowych. Więc teraz jest domyślnie wyłączony.
Aby uzupełnić odpowiedzi, nacisk Oracle na „zastąpienie” funkcji pamięci podręcznej zapytań to integracja memcached .