Query Cache

Query cache-ul a fost un mecanism esențial de optimizare a bazelor de date, deși implementarea sa a evoluat semnificativ de-a lungul timpului. Principiul este simplu: dacă aceeași interogare SQL este executată de mai multe ori cu aceleași date, nu este necesar să fie procesată de fiecare dată — rezultatul poate fi servit din memorie.

MySQL a oferit un query cache intern până la versiunea 8.0, când a fost eliminat. Motivul: pe serverele multi-core moderne cu workload-uri mixte (citire și scriere), query cache-ul devenea un bottleneck din cauza mutex-ului global necesar pentru invalidare. La fiecare operațiune de scriere (INSERT, UPDATE, DELETE), toate intrările din cache pentru tabelele afectate erau invalidate.

MariaDB (folosit de HostPedia și multe platforme de hosting) păstrează query cache-ul și l-a optimizat. Configurarea se face prin variabilele: query_cache_type (ON/OFF/DEMAND), query_cache_size (memorie alocată) și query_cache_limit (dimensiunea maximă a unui rezultat cache-at).

Alternative moderne la query cache-ul intern includ: ProxySQL (proxy SQL cu cache integrat), Redis sau Memcached (cache la nivel de aplicație), și ORM-uri cu cache layer (Doctrine, Eloquent).

Pentru site-urile WordPress, plugin-uri precum Redis Object Cache sau W3 Total Cache implementează caching la nivel de query prin stocarea rezultatelor în Redis sau Memcached. Acest lucru este mult mai eficient decât query cache-ul nativ, deoarece invalidarea poate fi controlată granular.

O regulă de bază: query cache-ul este eficient pentru site-uri cu raport mare de citire vs. scriere (bloguri, site-uri de prezentare) și ineficient pentru aplicații cu scrieri frecvente (e-commerce cu actualizări de stoc în timp real, rețele sociale).