La query viene memorizzata nella cache sull'installazione locale, ma mai sul server?

Question

Ho un sacco di problemi con la cache di query su un progetto: sto eseguendo un sapore Percona di MySQL, stesse versioni sia sul mio computer di sviluppo locale che sul server di produzione. Ora, abilitare la cache della query mi dà risultati eccellenti sulla mia macchina locale: quasi tutte le query che dovrebbero essere memorizzate nella cache, in effetti lo sono.

Ora, esattamente le stesse query non vengono memorizzate nella cache sul server di produzione. Tutto è esattamente lo stesso; le variabili mysql, i contenuti del database, il codebase, l'utente loggato, .. ma sulla produzione solo una manciata di query vengono memorizzate nella cache, le più importanti sono tutte ignorate. E non riesco a capire perché :-)

Quindi, cercando una soluzione, sto lavorando con la seguente query, utilizzata per selezionare gli ultimi 3 argomenti dalla tabella degli argomenti: (questo è il più "pesante" ! interrogazione ed è quello che voglio assolutamente essere memorizzate nella cache)

SELECT `topic`.* FROM `topics` AS `topic` 
LEFT OUTER JOIN `topics` AS `topic_helper` 
ON (`topic`.`id` = `topic_helper`.`id` 
     AND `topic_helper`.`created_on` < `topic`.`created_on`) 
GROUP BY `topic`.`id` HAVING COUNT(*) < 3 
ORDER BY `topic`.`created_on` DESC; 

Quindi, per iniziare, il SHOW VARIABLES LIKE '%query_cache% mi danno gli stessi risultati, sia a livello locale come sulla produzione:

+------------------------------+----------+ 
| Variable_name    | Value | 
+------------------------------+----------+ 
| have_query_cache    | YES  | 
| query_cache_limit   | 1048576 | 
| query_cache_min_res_unit  | 4096  | 
| query_cache_size    | 10485760 | 
| query_cache_strip_comments | OFF  | 
| query_cache_type    | ON  | 
| query_cache_wlock_invalidate | OFF  | 
+------------------------------+----------+ 

di eseguire la query di cui sopra viene memorizzato nella cache localmente dopo la prima esecuzione, come mi dice chiaramente n. SHOW PROFILE alla fine della sua traccia:

| Waiting for query cache lock | 0.000001 | 
| Waiting on query cache mutex | 0.000001 | 
| freeing items     | 0.000000 | 
| storing result in query cache | 0.000002 | 
| logging slow query    | 0.000001 | 
| cleaning up     | 0.000006 | 
+--------------------------------+----------+ 

Seconda chiamata restituisce la query dalla cache, come previsto.

Sul server di produzione, l'esecuzione di questa query non la memorizzerà mai nella cache. Il set di risultati è esattamente lo stesso, e non ci sono chiaramente dichiarazioni in uso che invaliderebbero il caching delle query (secondo il manuale su http://dev.mysql.com/doc/refman/5.1/en/query-cache-operation.html - Sono certo che la query di cui sopra soddisfi i requisiti per essere memorizzata nella cache.)

per completezza amore, l'uscita completa del SHOW PROFILE per quella stessa query sul server di produzione, si incolla qui: http://pastebin.com/7Jm5rmVd

Inoltre, vale la pena notare che, anche se la configurazione è esattamente lo stesso su entrambi i server, il mio locale la versione è 5.5.27, leggermente più nuova di quella in produzione 5.5.17-55. Potrebbe essere che questo è il problema ..?

ho confrontato il pieno SHOW VARIABLES; uscita da entrambi i miei server locale come server di produzione per vedere se qualcosa mancava, ma nulla si differenzia tranne che per il fuso orario del sistema e del percorso per i file di log, ecc ..

Quindi, potrebbe qualcuno di voi sa dove cercare il prossimo? O hai qualche idea di cosa potrebbe causare questo?

Answer 1

Utilizziamo il server Percona qui e anche MySQL della comunità.

Le cache delle query sono potenti e molto complicate. La cosa peggiore che MySQL potrebbe fare è restituire alcuni dati cache stantii.

MySQL memorizza non solo le query, ma anche i dati del database e utilizza indici per prestazioni aggiuntive.

Tutto ciò che potrebbe invalidare la cache della query, lo invalida.

Come regola generale, non ci concentriamo troppo sul fatto che venga memorizzato nella cache o no ...confidiamo che MySQL agisca in modo intelligente - se per qualche motivo pensa che qualcosa non debba essere memorizzato nella cache, non lo memorizza nella cache. Quello che facciamo però è assicurarci che le nostre domande siano il più possibile efficienti e semplici.

Se posso dire questo - penso che si verificheranno seri problemi di scalabilità indipendentemente dalla cache della query se la query di esempio è "una delle più utilizzate". Correrà come un cane senza gambe una volta che il server si diverte!

In base alla voce pastebin, è stata creata almeno una tabella temporanea, probabilmente a causa del join esterno (o dei GROUP BY).

Sono tutto per la normalizzazione, ma a volte le prestazioni richiedono un percorso alternativo.

È possibile non memorizzare in cache alcuni di questi dati, in una sorta di tabella di ricerca/riassunto? I trigger possono essere tuoi amici qui :)