Använd MySQL:s inbyggda frågecache istället för att försöka underhålla den själv. Det kommer automatiskt att rensa cachade frågor till tabeller när de skrivs till. Dessutom fungerar det i minnet så det borde vara väldigt effektivt...
Dessutom, cache inte bara frågor. Försök att cachelagra hela segment av programmet vid olika stadier i renderingscykeln. Så du kan låta MySQL cachelagra frågorna, sedan cachelagrar du varje enskild vy (renderad), varje enskilt block och varje sida. Sedan kan du välja om du vill hämta från cachen eller inte baserat på begäran.
Till exempel kan en icke-inloggad användare få hela sidan direkt från cachen. Men en inloggad användare kanske inte kan (på grund av användarnamn, etc). Så för honom kan du kanske återge 1/2 av dina vyer på sidan från cache (eftersom de inte beror på användarobjektet). Du får fortfarande fördelen av cachelagring, men det kommer att delas upp efter behov.
Om du verkligen förväntar dig mycket trafik är det definitivt värt att titta på Memcached
. Låt MySQL lagra dina frågor åt dig och lagra sedan alla cacheobjekt för användarland i memcache...
Redigera: För att svara på din redigering:
Filsystem kan bli långsamma om en enda katalog växer sig stor. Så länge du "avstånd mellan namn" efter katalog (så att varje katalog bara har en liten del av cachefiler), bör du klara dig ur den synvinkeln. När det gäller den exakta tröskeln kommer det verkligen att bero på din hårdvara och filsystem mer än något annat. Jag vet att EXT3 blir ganska långsam om det finns en mängd filer i en enda katalog (jag har kataloger med bokstavligen hundratusentals filer, och det kan ta upp till en halv sekund att helt enkelt stat() en av filerna, än mindre göra någon form av kataloglistning)...
Men inse att om du lägger till en annan server kommer du antingen att ha dubblering av cache (vilket inte är bra), eller kommer att behöva skriva om hela cachelagret. Finns det en anledning att inte använda Memcached redan från början?
Redigera 2: För att svara på din senaste redigering:
Det är fortfarande för svårt att ringa. Jag har en applikation som har en databas med cirka 1,5 miljarder rader (växer med cirka 500 000 per dag). Vi använder inte någon cachning på det alls eftersom vi inte har några samtidighetsproblem. Och även om vi gjorde det, skulle vi vara bättre att kasta fler MySQL-servrar på det istället för att lägga till cache eftersom någon form av cache skulle ha så låg träfffrekvens att det inte skulle vara värt utvecklingstiden att lägga till det.
Och det är anledningen till att jag är så övertygad om att inte cache för hastighet. Det kommer alltid att finnas ett objekt som inte finns i cachen. Så om du träffar en sida med ett av dessa objekt måste det fortfarande vara snabbt. Som en tumregel försöker jag cache allt som kommer att nås igen inom de närmaste minuterna (jag håller en tid att leva på cirka 5 minuter i produktion på andra applikationer i alla fall). Så om objekten inte får fler än några träffar under den tidsperioden, eller träfffrekvensen är mycket låg (mindre än 90 %), bryr jag mig inte om att cachelagra objektet...