Należy po prostu wyłączyć pamięć podręczną zapytań za pomocą
[mysqld]
query_cache_size = 0
a następnie uruchom ponownie mysql. Dlaczego miałbym to sugerować?
Pamięć podręczna zapytań zawsze będzie trafiać w InnoDB. Byłoby miło, gdyby MVCC InnoDB zezwalał na obsługę zapytań z pamięci podręcznej zapytań, jeśli modyfikacje nie wpływają na powtarzalne odczyty dla innych transakcji. Niestety InnoDB po prostu tego nie robi. Najwyraźniej masz wiele zapytań, które zostają unieważnione dość szybko i prawdopodobnie nie są ponownie używane.
W przypadku InnoDB w MySQL 4.0 pamięć podręczna zapytań została wyłączona dla transakcji. W MySQL 4.1+ InnoDB odtwarza ruch policjanta, gdy pozwala na dostęp do pamięci podręcznej zapytań dla poszczególnych tabel.
Z perspektywy twojego pytania powiedziałbym, że uzasadnienie usunięcia bufora zapytań nie jest tak dużym obciążeniem, ale tym, w jaki sposób InnoDB nim zarządza.
Więcej informacji na temat interakcji InnoDB z pamięcią podręczną zapytań znajduje się na stronach 213–215 książki „High Performance MySQL (Second Edition)” .
Jeśli wszystkie lub większość twoich danych to MyISAM, możesz skorzystać z oryginalnego pomysłu użycia SQL_NO_CACHE.
Jeśli masz połączenie InnoDB i MyISAM, będziesz musiał znaleźć odpowiednią równowagę dla swojej aplikacji na podstawie tego, jak wysokie są Twoje błędy w pamięci podręcznej. W rzeczywistości strony 209-210 tej samej książki wskazują przyczyny braków w pamięci podręcznej:
- Kwerenda nie może być buforowana, ponieważ zawiera niedeterministyczną konstrukcję (taką jak CURRENT_DATE) lub ponieważ jej zestaw wyników jest zbyt duży, aby ją zapisać. Oba typy nieusuwalnych zapytań zwiększają zmienną statusu Qcache_not_cached.
- Serwer nigdy wcześniej nie widział zapytania, więc nigdy nie miał szansy na buforowanie jego wyniku.
- Wynik zapytania był wcześniej buforowany, ale serwer go usunął. Może się to zdarzyć, ponieważ nie ma wystarczającej ilości pamięci, aby ją zachować, ponieważ ktoś poinstruował serwer, aby ją usunąć lub ponieważ została unieważniona
a podstawowymi przyczynami dużych braków pamięci podręcznej z kilkoma nieczytelnymi zapytaniami mogą być:
- Pamięć podręczna zapytań nie jest jeszcze ciepła. Oznacza to, że serwer nie miał okazji zapełnić pamięci podręcznej zestawami wyników.
- Serwer widzi zapytania, których wcześniej nie widział. Jeśli nie masz wielu powtarzających się zapytań, może się to zdarzyć nawet po rozgrzaniu pamięci podręcznej.
- Istnieje wiele unieważnień pamięci podręcznej.
AKTUALIZACJA 2012-09-06 10:10 EDT
Szukając najnowszych zaktualizowanych informacji, query_cache_limitustawiłeś 1048576 (1M). Ogranicza to każdy wynik ustawiony na 1M. Jeśli odzyskasz coś większego, po prostu nie będzie on buforowany. Chociaż query_cache_sizeustawiłeś 104857600 (100M), pozwala to tylko na 100 buforowanych wyników ustawionych w idealnym świecie. Jeśli wykonasz setki zapytań, fragmentacja nastąpi dość szybko. Masz również 4096 (4K) jako zestaw wyników minimalnego rozmiaru. Niestety, mysql nie ma wewnętrznego mechanizmu defragmentacji pamięci podręcznej zapytań.
Jeśli musisz mieć pamięć podręczną zapytań i masz dużo pamięci RAM, możesz wykonać następujące czynności:
SET GLOBAL query_cache_size = 0;
SELECT SLEEP(60);
SET GLOBAL query_cache_size = 1024 * 1024 * 1024;
w celu wyczyszczenia pamięci podręcznej zapytań. Tracisz wszystkie wyniki z pamięci podręcznej, więc uruchom te linie poza godzinami szczytu.
Przypisałbym również następujące:
- query_cache_size = 1G
- query_cache_limit = 8M
To pozostawia 23G pamięci RAM. Chciałbym podnieść następujące kwestie:
- innodb_buffer_pool_size = 12G
- key_buffer_size = 4G
To pozostawia 7G. Powinno to być odpowiednie dla połączeń OS i DB.
Należy pamiętać, że bufor buforowy buforuje tylko strony indeksowe MyISAM, natomiast pula buforów InnoDB buforuje dane i indeksy.
Jeszcze jedno zalecenie: uaktualnij do MySQL 5.5, abyś mógł skonfigurować InnoDB dla wielu procesorów i wielu wątków dla odczytu / zapisu we / wy.
Zobacz moje wcześniejsze posty na temat używania MySQL 5.5 w połączeniu z dostępem do wielu procesorów dla InnoDB
AKTUALIZACJA 2012-09-06 14:56 EDT
Moja metoda czyszczenia pamięci podręcznej zapytań jest dość ekstremalna, ponieważ łączy buforowane dane i tworzy zupełnie inny segment pamięci RAM. Jak zauważyłeś w swoim komentarzu FLUSH QUERY CACHE(jak sugerowałeś), a nawet RESET QUERY CACHEbyłoby lepiej. Dla wyjaśnienia, kiedy powiedziałem „brak mechanizmu wewnętrznego”, miałem na myśli dokładnie to. Defragmentacja jest konieczna i musi zostać wykonana ręcznie. Musiałby to być crontabbed .
Jeśli wykonujesz DML (INSERT, UPDATE, DELETE) częściej na InnoDB niż na MyISAM, powiedziałbym, że całkowicie usuwam pamięć podręczną zapytań, co powiedziałem na początku.