Cześć,
W jaki sposób cachować zaawansowane zapytania idące do bazy które wyciągają przykładowo 1000 rekordów i więcej? Zapisywać je do jakiegoś pliku i później tylko plik otwierać? Jeśli tak to jaki sens ma cachowanie skoro plik i tak i tak trzeba otworzyć i obsłużyć tak jak bazę danych i jej zapytanie. Jakie dane warto cachować i w jaki najbardziej optymalny sposób?

I drugie pytanie tak na marginesie, co jest bardziej wydajne:
- Jedno zapytanie do bazy wyciągające 10 000 rekordów
- Dziesięc zapytań do bazy wyciągających 1 000 rekordów
Chodzi dokładnie o to, że wyciągam jednym zapytaniem wszystkie rekordy i później w php je sobie rozdzielam lub wyciągam kilkoma różnymi zapytaniami części rekordów o określonych warunkach w zapytaniu.

Skad ten pomysl ze dane z cache masz jakos obslugiwac tak jak baze danych? Do cache wstawiasz dane przetworzone, gotowe do uzycia.

Jesli np. na stronie glownej wyswietlasz 5 ostatnich newsow, to do cache wstawiasz tylko te ostatnie 5 newsow. Nie musisz juz leciec do bazy za kazdym razem po ostatnie 5 newsow tylko bierzesz i wyswietlasz to z cache

Czyli cachowanie polega właśnie na zapisie pobranych danych z bazy do pliku a później ich tylko wyświetleniu? Czy są jeszcze inne metody cachowania?
Jak taki cache aktualizować? Można tzw. pseudokronem sprawdzającym przy wejściu na stronę czy minęło tyle i tyle czasu od ostatniego pobrania czy jest może jakieś lepsze rozwiązanie na aktualizacje scachowanych danych? Zakładając oczywiście, że normalny cron z góry odpada

Pomysłów na cache jest tyle co na sam kod Cachowanie samych zapytań nie ma za bardzo sensu bo sam MySQL to robi [query cache].
Samo odświeżanie cache to też kwestia konstrukcji projektu

Ja w ostanim projekcie obrałem taki model, że cachuje już gotowy html np. menu, gdy szablon o niego woła to sprawdzam czy istnieje plik caches/menu/html.js - jesli tak to pobeiram z niego dane, odkodowuje [json jest chyba najwygodniejszy - stad rozszerzenie JS] i zwracam gotowy.
Jako, że pokomplikowane menu to nawet 40 zapytań (prostych w petli ale jednak) to oszczędzam sporo czasu. Na cachowaniu np. newsów wiele się nie utarga ale jednak.
Tutaj cache tworzysz przy pierwszym wyświetleniu, kasujesz przy zmianie lub usuwaniu newsa oraz jesli cache nie uzywane np. tydzien/miesiac [crontab co tydzien/miesiac sprawdzjacy daty ostaniego otwarcia pliku].
Generalnie zasada jest taka, że cachuje się najbardziej gotowe dane ale bez przesady - jeśli jakiś danych używasz często (np. u mnie tabela settings) to nie ma sensu cachować każdego ustawienia osobno gdzie jest użyte - cachujesz sobie całą tabele do pliku.
Samo cachowanie ma też wiele poziomów, można je relizować już na poziomie bazy danych w postaci tabel trzymanych w ramie (po co trzymać dane o zalogowanych userach na hdd? zmieniają się często a jak znikną w wyniku nagłego padu to też sie kuku nie stanie).

Za pozno w mojej strefie czasowej na dłuży post


Edit: Się mi przypomniało - warto też cachować generowany RSS jeśli strona jest w miarę popularna. Nie warto generować dla każdego z osobna - to duża strata mocy przez która o mało Yahoo swego czasu nie padło (dla zainteresowanych an Yahoo Dev jest art).
Generujesz raz, kasujesz jak dojdzie jakaś treść obejmująca ten kanał [np. nowy news dla kanału newsów].

Nie musze wspominać, ze jest to bez sensu dla kanału komentarzy?

Mozesz ustawic waznosc cache np. na 10 minut. Klasa do cache, sama bedzie sprawdzac, czy minelo te 10 minut i albo zwroci ci dane, albo powie ze juz są nie akutalne i musisz je wygenerowac na nowo

Mozesz tez sam czyscic cache po dodaniu newsa.