Nu se poate spune că cache-ul de interogare este automat mai eficient decât absența acestuia. Cache-ul necesită timp, astfel încât să puteți obține numai bani din memoria cache dacă economiile depășesc costurile. Și depinde de încărcarea serverului.
Teoretic, pentru a determina dacă un cache este util sau nu, puteți compara, prin compararea cantității de lucru pe care serverul ar trebui să o facă cu cache-ul activat și dezactivat. Dacă memoria cache este dezactivată, serverul execută toate cererile de citire și scriere, iar în primul caz - generează și returnează rezultatele. În cazul în care cache-ul este activat, atunci când procesarea orice cerere de citire, trebuie să verificați mai întâi cache-ul, și apoi reveni fie rezultatul stocat, sau (în cazul în care nu este în cache) pentru a efectua o interogare pentru a genera un set de rezultate și trimite-l la client. La procesarea oricărei solicitări de scriere, trebuie să o executați mai întâi și apoi să verificați dacă este necesar să declarați orice intrări în memoria cache nevalidă.
Deși toate acestea arata destul de simplu, este dificil să se prevadă cu exactitate avantajele utilizării cache-ului. De asemenea, este necesar să se ia în considerare factorii externi. De exemplu, cache-ul de interogare poate reduce timpul necesar pentru formarea rezultatului, dar nu și timpul necesar să-l trimită la client, și anume, acesta poate fi factorul dominant.
Una dintre cele mai ușoare modalități de a înțelege dacă cache-ul dă o victorie este să se uite la raportul de hit în cache. Afișează câte cereri au fost difuzate din cache și nu au fost efectuate de server de la zero. Când serverul primește un SELECT, acesta mărește una dintre cele două variabile de stare: Qcache_hits sau Com_select, în funcție de dacă cererea a fost stocată în cache sau nu. Prin urmare, raportul de hit în cache se calculează folosind formula Qcache_hits / (Qcache_hits + Com_select).
Orice interogare SELECT care nu este difuzată din memoria cache se numește o pierdere de memorie cache. Nu puteți intra în memoria cache din următoarele motive.
• Solicitare previne depozitarea temporară ca conține fie o structură non-deterministă (de exemplu, funcția CURRENT_DATE), sau pentru că setul de rezultate este prea mare pentru neniya păstrează în memoria cache. În ambele cazuri, variabila Qcache_not_cached este incrementată cu una.
• Serverul nu a văzut încă o astfel de solicitare, astfel încât nu a putut să-și cacheze rezultatul.
• Rezultatul cererii a fost anterior stocat în memoria cache, dar serverul a șters-o. Acest lucru se poate întâmpla din cauza lipsei de memorie, datorită faptului că cineva a spus serverului să șterge cererea din memoria cache sau pentru că înregistrarea a fost declarată nevalidă.
Dacă numărul de eșecuri din memoria cache este mare și numărul cererilor care nu sunt memorate în cache este foarte mic, atunci una dintre următoarele afirmații este adevărată.
• Memoria cache nu sa încălzit încă, adică serverul nu a avut timp să umple cache-ul cu rezultatele interogării.
• Serverul vede în mod constant cereri care nu au fost îndeplinite înainte. Dacă numărul de solicitări repetate este mic, acest lucru se poate întâmpla chiar și atunci când cache-ul este "încălzit".
• De prea multe ori, intrările din memoria cache sunt declarate nevalide.
Intrarea poate deveni nevalidă din cauza fragmentării, a lipsei de resurse sau a modificării datelor. Dacă ați luat cache-ul are suficientă memorie și parametrul query_cache_min_res_unit configurat corect, invalidarea cea mai mare parte din cauza modificării valorii stocate. Aflați date cât de multe cereri au modificat, permit variabilele de stare Com_ * (Com_update, Com_delete, etc ...), și cât de multe cereri au fost declarate nevalabile din cauza lipsei de memorie - Qcache_lowmem_prunes variabile.
Este logic să se ia în considerare costurile de invaliditate separat de rata de succes. Să presupunem, de exemplu, că o singură lectură este citită dintr-o singură masă, în timp ce rata de lovire este de 100%, iar în cealaltă, doar actualizarea. Dacă vom calcula coeficientul de lovire pentru variabilele de stare, va fi de 100%. Dar chiar și în acest caz, utilizarea cache-ului poate fi ineficientă, deoarece încetinește executarea cererilor de actualizare. La procesarea orice cerere de reînnoire este necesar să se verifice, dacă să declare nule și neavenite orice date stocate în memoria cache, ci pentru că răspunsul va fi invariabil „nu“, atunci toate aceste lucrări a fost făcut în zadar. Acest tip de problemă poate fi ignorată, dacă nu analizați împreună numărul de cereri necotate și rata de succes.
Serverul la care un amestec de operații de scriere și citire în cache din aceleași tabele echilibrat, nu beneficiază întotdeauna de prezența cache de interogare. Orice operație de scriere face ca cererile din cache să fie invalide, în timp ce orice operație de citire introduce o nouă solicitare în memoria cache. O victorie poate fi obținută numai dacă aceste cereri sunt apoi scoase din cache.
Dacă rezultatul stocat devine invalid înainte ca serverul să primească din nou aceeași comandă SELECT, întreaga operație de salvare a fost o pierdere de timp și de memorie. Pentru a înțelege dacă există această situație, comparați valorile variabilelor Com_select și Qcache_inserts. În cazul în care aproape toate SELECT declarațiile nu se încadrează în cache-ul (acest lucru crește valoarea Com_select), după care seturile lor de rezultate sunt memorate în cache, atunci Qcache_inserts vor diferi puțin de Com_select. Și ar fi de dorit ca valoarea Qcache_inserts să fie, în esență, mai mică de Com_select, cel puțin după "încălzirea" unui cache.
Pentru fiecare aplicație există o dimensiune a cache-ului potențial finit, chiar dacă nu există operațiuni de scriere. Dimensiunea potențială este cantitatea de memorie necesară pentru a stoca toate cererile memorate în cache pe care o aplicație le poate rula. Teoretic, pentru majoritatea cazurilor această dimensiune este foarte mare. Dar, în practică, pentru multe aplicații, este mult mai mic decât v-ați aștepta, deoarece majoritatea intrărilor din cache devin invalide. Chiar dacă alocați o mulțime de memorie pentru cache-ul de interogare, acesta nu va umple niciodată mai mult decât dimensiunea potențială a cache-ului.
Este necesar să se monitorizeze cât de mult este alocată memoria cache-ului. Dacă nu este folosită toată memoria, reduceți mărimea cache-ului, dacă există adesea o ieșire din cauza lipsei de memorie, creșteți-o. Cu toate acestea, dimensiunea excesului de cache nu este atât de înfricoșător; datorită faptului că este alocată puțin mai mult sau puțin mai puțină memorie decât este de fapt necesară, performanța nu va suferi prea mult. Problema apare atunci când nu utilizați o mulțime de memorie sau solicitările sunt expulzate din memoria cache atât de des, încât toate cache-urile duc numai pierderi.
De asemenea, trebuie să potriviți mărimea cache-ului interogării cu alte cache-uri ale serverului, de exemplu, bazinul de rezervă InnoDB sau memoria cache MyISAM. Este imposibil să se propună un coeficient pentru toate ocaziile sau o formulă simplă, deoarece echilibrul adecvat depinde de aplicația particulară.