Abbiamo effettuato l'aggiornamento a MySQL 5.6 e abbiamo iniziato a vedere un aumento significativo del caricamento del server db, e alla fine abbiamo scoperto che il query_cache_typedefault è spento a partire da 5.6.

L'abbiamo abilitato di nuovo e vediamo diminuire il caricamento, perché questo valore è disabilitato di default a partire da MySQL 5.6? Non riesco a vedere il problema abilitato.

Hai bisogno della storia di InnoDB per capire il perché. Eccolo:

STORIA DELLA GUERRA

InnoDB e la cache delle query sono in costante stato di guerra. InnoDB tende ad essere molto pesante quando si ispezionano le modifiche nel pool di buffer InnoDB e si esegue il controllo incrociato della cache delle query per le stesse modifiche.

TRATTATO DI PACE

Prima di MySQL 5.0, la cache delle query era disabilitata per InnoDB. Ora, InnoDB interagisce con esso. Per semplificare le cose, puoi semplicemente disabilitare la cache delle query impostando query_cache_size su 0.

Secondo la documentazione MySQL su query_cache_time

Se il server viene avviato con query_cache_type impostato su 0, non acquisisce affatto la cache della query mutex, il che significa che la cache della query non può essere abilitata in fase di esecuzione e si riduce l'overhead nell'esecuzione della query.

CONDIZIONI DEL SOSTENITORE

L'impostazione di query_cache_size su 0 non è una soluzione adatta a tutti.

Il motivo della guerra, in primo luogo, è il sovraccarico. InnoDB controllerà sempre le modifiche. Una cache di query più grande renderà InnoDB molto più difficile. Disabilitando la cache delle query, InnoDB e Query Cache saranno felici. Tuttavia, tu (lo sviluppatore / DBA) potresti essere una vittima di quella guerra con cattive prestazioni di interrogazione, anche con un simile trattato di pace in atto.

A seconda di quanto segue

• Carico di lavoro
• Frequenza delle modifiche
• Frequenza di lettura degli stessi dati

dovresti impostare query_cache_size sul numero che ritieni aumenti le prestazioni (equivale a iniziare un movimento clandestino).

EPILOGO

Nel caso ti stia chiedendo dove mi sia venuta in mente questa storia di guerra, per favore vedi il mio vecchio post

• Sep 05, 2012: Ne vale la pena l'overhead della frequente invalidazione della cache delle query?

Leggilo attentamente perché l'ho imparato dalle pagine 209-215 di MySQL ad alte prestazioni (2a edizione)

Ho consigliato di disabilitare la cache delle query ad altri prima

• Sep 25, 2013: invalidare le voci della cache delle query (chiave)
• Sep 26, 2013: il valore di hit della cache delle query non cambia nel mio database
• Dec 23, 2013: MySQL con elevato utilizzo di CPU e memoria

NOTA: mi rendo conto che la domanda riguardava query_cache_type . Ha un effetto sulla cache delle query. La disabilitazione della cache schiaccia il dominio di InnoDB su di essa. L'impostazione manuale di query_cache_type forza semplicemente lo sviluppatore / DBA a riflettere attentamente sul tipo di query che la cache delle query incontrerà.

Ho un post sul blog che spiega perché questo è qui .

La versione breve: la cache delle query causa problemi di scalabilità su macchine multi-core. Quindi ora è disabilitato per impostazione predefinita.

Per completare le risposte, la spinta di Oracle a "sostituire" la funzionalità della cache delle query è l' integrazione memcached .