[pelmered]

Jag har massa olika om hur man ska göra med MySQL:s query cache. Vissa säger att det är bra.
Andra säger att det omodern skit och att det ska vara avstängt om man kör InnoDB och att man bara ska använda innodb_buffer_pool_size.

De tycker alltså att man ska använda följande:

query_cache_size = 0
query_cache_type = 0

Istället ska man använda innodb_buffer_pool_size så att större delen av serverns ram fylls upp av detta(~80-85% av totala mängden RAM om man kör DB på egen server).

Vad säger experterna här på WN?
Är det beroende av hur databasen används? Vad beror det på i så fall?

Jag är mycket tacksam för svar samt en konstruktiv diskussion kring det här.

[Clarence]

Det är helt beroende på din specifika load. Det är sant att det gör mycket mindre nytta med buffer pool, men en hit mot QC är mycket snabbare än en hit mot buffer pool .. men är också mindre återanvändbar. Vid låg QC hitrate kan det också vara nära noll nytta eller till och med negativ inverkan att underhålla cachen för väldigt få hits.

I min mening gör man ibland-ofta bättre att stänga av den om man har en bra MVC-struktur och där har en bra cache-policy (du slår aldrig memcache prestandan med MySQL, bara auth drar mer än en fetch). Men den gör i princip alltid nytta om man inte har det eller också servar legacy kod.

Det lättaste sättet att veta hur din load hanterar det är att sätta upp en temporär server som du sedan kör playback av dina queries mot (med t ex percona playback) med QC av och på. Tänk på att du måste värma upp buffer poolen först för att få relevanta resultat!

[pelmered]

Ursprungligen postat av Clarence

Det är helt beroende på din specifika load. Det är sant att det gör mycket mindre nytta med buffer pool, men en hit mot QC är mycket snabbare än en hit mot buffer pool .. men är också mindre återanvändbar. Vid låg QC hitrate kan det också vara nära noll nytta eller till och med negativ inverkan att underhålla cachen för väldigt få hits.

I min mening gör man ibland-ofta bättre att stänga av den om man har en bra MVC-struktur och där har en bra cache-policy (du slår aldrig memcache prestandan med MySQL, bara auth drar mer än en fetch). Men den gör i princip alltid nytta om man inte har det eller också servar legacy kod.

Det lättaste sättet att veta hur din load hanterar det är att sätta upp en temporär server som du sedan kör playback av dina queries mot (med t ex percona playback) med QC av och på. Tänk på att du måste värma upp buffer poolen först för att få relevanta resultat!

Tack för bra svar!
Det bästa verkar alltså vara att i de flesta fall skippa QC helt och istället köra memcached eller redis för exakta matchar och att man alltid hämtar hela objekt/rader ur databasen (ORM-struktur) som man sedan lagrar i minnescachen?
Om man cachar alla objekt i minnet kommer man ju i princip aldrig köra samma query fler än en gång mot samma dataset vilket gör att QCn inte kommer vara effektiv vilket gör att det då är det bättre att stänga av den. Har jag förstått det rätt då?

Det är ju ganska logiskt egentligen.

[Clarence]

Ja du har förstått det helt rätt. Men att underhålla en objekt-cache är inte alltid det lättaste och smidigaste. Vill du ha live-uppdateringar där du har modeller beroende av andra modeller och ska cacha det i memcache så kan du få en jobbig process för att hålla memcache up to date. QC är där istället en no-brainer, som dock blir mindre effektiv vid väldigt mycket writes.

Sen är det ju sällan projekt med lite större kodbas inte har väldigt varierande kod från olika tidsperioder och kvalitet.

[pelmered]

Grymt! Nu blev det mycket klarare hur man ska förhålla sig till det här.
Tack så mycket!