kiedy SQL_NO_CACHE nie wystarcza Opcje

[konrad.b]

Witam wszystkich,

Próbuję właśnie przetestować prędkości różnego rodzaju zapytań, ale nie pozwala mi na to cache'owanie wyników. Za pierwszym uruchomieniem wszystko wygląda tak, jak się spodziewałem (oczekiwanie około 4 sekund), ale każde następne to już ułamki sekund.. Dowiedziałem się, że użycie w zapytaniach wyrażenia SQL_NO_CACHE powinno wyeliminować takie zachowanie, jednak w moim przypadku nic się nie zmieniło.
Użyłem również poleceń: RESET QUERY CACHE oraz SET SESSION query_cache_type = 0 i jak się domyślacie - cały czas nic...

Jakieś sugestie, pomysły?

[Mchl]

A skąd wiesz, że to cache akurat? Sprawdzasz czy rośnie Qcache_hits?

http://dev.mysql.com/doc/refman/5.0/en/que...aintenance.html

Pamiętaj, że przy pierwszym zapytaniu do danej tabeli, MySQL otwiera jej pliki na dysku i ładuje ją do pamięci. Potem jeśli już cała siedzi w pamięci, działanie jest dużo szybsze. Testy wydajności powinno się prowadzić symulując rzeczywiste warunki. Jeśli tabela jest często używana w Twojej aplikacji, to można zakładać, że raczej zawsze będzie dostępna w pamięci.

Jak chcesz pozamykać pootwierane tabele: FLUSH TABLES tabela

Ten post edytował Mchl 13.05.2010, 20:10:27

[konrad.b]

Aha, nie wiedziałem, że mysql zapisuje pliki na dysku... Tak czy inaczej pierwszy uruchomienie zawsze będzie wolniejsze, a w mojej sytuacji to własnie pierwsze uruchomienie jest najważniejsze.
Czy da się wyłączyć zapisywanie? Zwyczajnie w celach testowych?

[Mchl]

A myślałeś że gdzie dane są trzymane?

Masz silnik MEMORY, który wszystkie dane trzyma w RAMie, tylko że jak zatrzymasz serwer, to wszystkie dane z tych tabel idą do /dev/null

Inny pomysł, to załadowanie tych tabel zanim będą potrzebne.