MySQL pozwala nam tworzyć instrukcje select z użyciem opcji SQL_CACHE i SQL_NO_CACHE. Te opcje wpływają na buforowanie wyników zapytania w pamięci podręcznej zapytań. Ale do jakich zapytań lepiej użyć opcji SQL_CACHE i dla której SQL_NO_CACHE jeden? A może lepiej nie używać go w ogóle?Najlepsze praktyki MySQL do używania SQL_CACHE i SQL_NO_CACHE
Generalnie nie powinieneś w ogóle tego używać. SQL_CACHE jest niezbędny tylko wtedy, gdy zapytania nie są buforowane domyślnie, które są w domyślnej konfiguracji. SQL_NO_CACHE jest przydatny, jeśli wiesz, że określone zapytanie nie zostanie ponownie użyte w najbliższej przyszłości, szczególnie jeśli zestaw wyników jest duży. Celem jest uniknięcie zaśmiecania pamięci podręcznej wynikami, które nie będą potrzebne ponownie.
Używam SQL_NO_CACHE podczas debugowania prędkości zapytania.
Proszę dopracować. – Pacerier
Podczas testowania zapytań warto zmierzyć czas ich wykonywania, bez pobierania ich z pamięci podręcznej. Pobieranie z pamięci podręcznej jest znacznie szybsze niż pobieranie z bazy danych, dlatego porównywanie wyników bez wiedzy, czy pochodzi z bazy danych czy z pamięci podręcznej, nie ma sensu. –
W szczególności w odniesieniu do SQL_NO_CACHE - użyj tego, jeśli buforowanie wyniku nie przyniesie korzyści później. Powodem, dla którego powinieneś to zrobić, jest to, że jeśli masz wiele zapytań, które przechowują w pamięci podręcznej, ale nigdy nie są używane, spowolnisz pracę z MySQL, ponieważ spędza on coraz więcej czasu na zarządzaniu pamięcią podręczną. Staje się to szczególnie widoczne, gdy ludzie ustawiają naprawdę duże rozmiary query_cache, gdy czas na opróżnianie starych wpisów rośnie wraz z rozmiarem. Dlatego istnieje opcja 0,1,2 do zmiany zachowania query_cache w mySQL. – Ross
@Michael, W rzeczywistości zalecane ustawienie dla serwerów produkcyjnych polega na włączaniu buforowania ** off ** zapytania. – Pacerier
@Pacerier To naprawdę zależy od obciążenia. –