Vous devez simplement désactiver le cache de requête avec
[mysqld]
query_cache_size = 0
puis redémarrez mysql. Pourquoi est-ce que je suggérerais ça ???
Le cache de requêtes sera toujours en tête avec InnoDB. Ce serait bien si le MVCC d'InnoDB permettait aux requêtes d'être servies à partir du cache de requêtes si les modifications n'affectaient pas les lectures répétables pour d'autres transactions. Malheureusement, InnoDB ne fait tout simplement pas cela. Apparemment, vous avez beaucoup de requêtes qui sont invalidées assez rapidement et qui ne sont probablement pas réutilisées.
Pour InnoDB sous MySQL 4.0, le cache de requêtes a été désactivé pour les transactions. Pour MySQL 4.1+, InnoDB joue le flic du trafic lorsqu'il autorise l'accès au cache de requêtes par table.
Du point de vue de votre question, je dirais que la justification de la suppression du cache de requêtes n'est pas tant la surcharge, mais la façon dont InnoDB le gère.
Pour plus d'informations sur la façon dont InnoDB interagit avec le cache de requêtes, veuillez lire les pages 213 à 215 du livre "High Performance MySQL (Second Edition)" .
Si la totalité ou la majorité de vos données sont MyISAM, vous pouvez utiliser votre idée originale d'utiliser SQL_NO_CACHE.
Si vous avez un mélange d'InnoDB et de MyISAM, vous devrez trouver le bon équilibre pour votre application en fonction de la hauteur de vos échecs de cache. En fait, les pages 209-210 du même livre soulignent les raisons des échecs de cache:
- La requête ne peut pas être mise en cache, soit parce qu'elle contient une construction non déterministe (telle que CURRENT_DATE), soit parce que son jeu de résultats est trop volumineux pour être stocké. Les deux types de requêtes non mises en cache incrémentent la variable d'état Qcache_not_cached.
- Le serveur n'a jamais vu la requête auparavant, il n'a donc jamais eu la possibilité de mettre en cache son résultat.
- Le résultat de la requête était précédemment mis en cache, mais le serveur l'a supprimé. Cela peut se produire parce qu'il n'y avait pas assez de mémoire pour le conserver, parce que quelqu'un a demandé au serveur de le supprimer ou parce qu'il a été invalidé
et les causes profondes des échecs de cache élevés avec peu de requêtes impossibles à mettre en cache peuvent être:
- Le cache de requêtes n'est pas encore chaud. Autrement dit, le serveur n'a pas eu la possibilité de remplir le cache avec des jeux de résultats.
- Le serveur voit des requêtes qu'il n'a jamais vues auparavant. Si vous n'avez pas beaucoup de requêtes répétées, cela peut se produire même après le réchauffement du cache.
- Il existe de nombreuses invalidations de cache.
MISE À JOUR 2012-09-06 10:10 EDT
À la recherche de vos dernières informations mises à jour, vous avez query_cache_limitdéfini 1048576 (1M). Cela limite tout jeu de résultats à 1M. Si vous récupérez quelque chose de plus grand, il ne sera tout simplement pas mis en cache. Bien que vous ayez query_cache_sizedéfini 104857600 (100M), cela ne permet que 100 résultats mis en cache dans un monde parfait. Si vous effectuez des centaines de requêtes, la fragmentation se produira assez rapidement. Vous avez également 4096 (4K) comme jeu de résultats de taille minimale. Malheureusement, mysql n'a pas de mécanisme interne pour défragmenter le cache de requêtes.
Si vous devez avoir le cache de requêtes et que vous avez tellement de RAM, vous pouvez exécuter ce qui suit:
SET GLOBAL query_cache_size = 0;
SELECT SLEEP(60);
SET GLOBAL query_cache_size = 1024 * 1024 * 1024;
afin de purger le cache de requête. Vous perdez tous les résultats mis en cache, exécutez donc ces lignes pendant les heures creuses.
Je voudrais également attribuer les éléments suivants:
- query_cache_size = 1G
- query_cache_limit = 8M
Cela laisse 23G de RAM. Je voudrais soulever ce qui suit:
- innodb_buffer_pool_size = 12G
- key_buffer_size = 4G
Cela laisse 7G. Cela devrait être suffisant pour les connexions OS et DB.
Gardez à l'esprit que le tampon clé ne met en cache que les pages d'index MyISAM, tandis que le pool de tampons InnoDB met en cache les données et les index.
Une autre recommandation: passez à MySQL 5.5 pour pouvoir configurer InnoDB pour plusieurs CPU et plusieurs threads pour les E / S en lecture / écriture.
Voir mes articles précédents sur l'utilisation de MySQL 5.5 en conjonction avec l'accès à plusieurs processeurs pour InnoDB
MISE À JOUR 2012-09-06 14:56 EDT
Ma méthode pour effacer le cache de requête est plutôt extrême car elle arrose les données mises en cache et forme un segment de RAM complètement différent. Comme vous l'avez souligné dans votre commentaire, FLUSH QUERY CACHE(comme vous l'avez suggéré) ou même ce RESET QUERY CACHEserait mieux. Pour plus de précision, lorsque j'ai dit "pas de mécanisme interne", je voulais dire exactement cela. La défragmentation est nécessaire et doit être effectuée manuellement. Il devrait être contrôlé .
Si vous faites du DML (INSERT, UPDATEs, DELETEs) sur InnoDB plus souvent que sur MyISAM, je dirais supprimer complètement le cache de requête, ce que j'ai dit au début.