La risposta al titolo non è sempre sì. La vecchia query cache di MySQL memorizzava risultati delle SELECT, ma le scritture ne causavano l’invalidazione e la gestione poteva diventare un collo di bottiglia. È stata deprecata in MySQL 5.7.20 e rimossa in MySQL 8.0: le vecchie direttive query_cache non sono un’ottimizzazione da aggiungere a un server moderno.
Cosa misurare oggi
Parti dalle query lente, dai piani di esecuzione e dagli indici. Il buffer pool InnoDB conserva pagine di dati e indici: non è una cache dei risultati delle query. Dimensionarlo richiede memoria disponibile, carico reale e misurazioni. Una cache applicativa può essere utile per risultati ripetuti, ma deve definire durata, invalidazione e gestione dei dati personali.
MariaDB è un prodotto distinto e può avere opzioni diverse. Controlla il risultato di SELECT VERSION(); e la documentazione corrispondente prima di applicare configurazioni. Confronta tempi e carico a parità di dati: una singola query veloce dopo un primo accesso non dimostra l’efficacia di una configurazione.
Un controllo concreto su MySQL 8
SELECT VERSION();
SHOW VARIABLES LIKE 'query_cache%';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';Su MySQL 8 la seconda istruzione non deve trovare le vecchie variabili della query cache. La terza restituisce la dimensione del buffer pool, in byte. Non aumentarla soltanto perché una query è lenta.
Prendi una SELECT reale e leggine il piano con EXPLAIN SELECT ..., sostituendo i puntini con la query completa. Controlla accesso alle tabelle, indici scelti e righe stimate. Su una copia del database confronta poi la stessa query prima e dopo una modifica agli indici o alla logica. Misura più esecuzioni a parità di dati e carico: il primo accesso può essere più lento perché le pagine non sono ancora in memoria.