Sie sollten den Abfrage-Cache einfach mit deaktivieren
[mysqld]
query_cache_size = 0
und starten Sie mysql neu. Warum sollte ich das vorschlagen ???
Der Abfrage-Cache wird immer mit InnoDB zusammenarbeiten. Es wäre schön, wenn das MVCC von InnoDB die Abfragen aus dem Abfrage-Cache bedienen würde, wenn Änderungen keine Auswirkungen auf wiederholbare Lesevorgänge für andere Transaktionen haben. InnoDB macht das leider nicht. Anscheinend haben Sie viele Anfragen, die ziemlich schnell ungültig werden und wahrscheinlich nicht wiederverwendet werden.
Für InnoDB unter MySQL 4.0 wurde der Abfrage-Cache für Transaktionen deaktiviert. Ab MySQL 4.1 spielt InnoDB Traffic Cop, wenn der Zugriff auf den Abfrage-Cache tabellenweise gewährt wird.
Aus der Perspektive Ihrer Frage würde ich sagen, dass die Rechtfertigung für das Entfernen des Abfragecaches nicht so sehr der Overhead ist, sondern wie InnoDB ihn verwaltet.
Weitere Informationen zur Interaktion von InnoDB mit dem Abfragecache finden Sie auf den Seiten 213-215 des Buches "High Performance MySQL (Second Edition)" .
Wenn alle oder ein Großteil Ihrer Daten MyISAM sind, können Sie mit Ihrer ursprünglichen Idee, SQL_NO_CACHE zu verwenden, fortfahren.
Wenn Sie eine Mischung aus InnoDB und MyISAM haben, müssen Sie das richtige Gleichgewicht für Ihre Anwendung finden, basierend auf der Höhe Ihrer Cache-Fehler. Tatsächlich verweisen die Seiten 209-210 desselben Buches auf Gründe für Cache-Fehler:
- Die Abfrage kann nicht zwischengespeichert werden, entweder weil sie ein nicht deterministisches Konstrukt enthält (wie CURRENT_DATE) oder weil die Ergebnismenge zu groß zum Speichern ist. Beide Arten von nicht zwischengespeicherten Abfragen erhöhen die Statusvariable Qcache_not_cached.
- Der Server hat die Abfrage noch nie gesehen, daher hatte er nie die Möglichkeit, das Ergebnis zwischenzuspeichern.
- Das Ergebnis der Abfrage wurde zuvor zwischengespeichert, aber der Server hat es entfernt. Dies kann vorkommen, weil nicht genügend Arbeitsspeicher vorhanden ist, weil der Server angewiesen wurde, ihn zu entfernen, oder weil er ungültig wurde
und die Hauptursachen für hohe Cache-Fehler mit wenigen nicht zwischenspeicherbaren Abfragen können sein:
- Der Abfragecache ist noch nicht warm. Das heißt, der Server hatte keine Chance, den Cache mit Ergebnismengen zu füllen.
- Der Server sieht Abfragen, die er noch nicht gesehen hat. Wenn Sie nicht viele wiederholte Abfragen haben, kann dies auch nach dem Aufwärmen des Caches passieren.
- Es gibt viele Cache-Invalidierungen.
UPDATE 06.09.2012 10:10 EDT
Wenn Sie Ihre letzten aktualisierten Informationen anzeigen, haben Sie query_cache_limit1048576 (1M) festgelegt. Dies begrenzt jede Ergebnismenge auf 1 Million. Wenn Sie etwas größeres abrufen, wird es einfach nicht zwischengespeichert. Während Sie query_cache_size104857600 (100M) festgelegt haben, sind in einer perfekten Welt nur 100 zwischengespeicherte Ergebnisse zulässig. Wenn Sie Hunderte von Abfragen durchführen, kommt es relativ schnell zu einer Fragmentierung. Sie haben auch 4096 (4 KB) als Ergebnismenge für die Mindestgröße. Leider verfügt mysql über keinen internen Mechanismus zum Defragmentieren des Abfragecaches.
Wenn Sie den Abfrage-Cache haben müssen und über so viel RAM verfügen, können Sie Folgendes ausführen:
SET GLOBAL query_cache_size = 0;
SELECT SLEEP(60);
SET GLOBAL query_cache_size = 1024 * 1024 * 1024;
um den Abfrage-Cache zu leeren. Sie verlieren alle zwischengespeicherten Ergebnisse. Führen Sie diese Zeilen daher außerhalb der Spitzenzeiten aus.
Ich würde auch folgendes vergeben:
- query_cache_size = 1G
- query_cache_limit = 8 Millionen
Damit verbleiben 23G RAM. Ich würde folgendes ansprechen:
- innodb_buffer_pool_size = 12G
- key_buffer_size = 4G
Das lässt 7G. Dies sollte für Betriebssystem- und DB-Verbindungen ausreichend sein.
Beachten Sie, dass der Schlüsselpuffer nur MyISAM-Indexseiten zwischenspeichert, während der InnoDB-Pufferpool Daten und Indizes zwischenspeichert.
Eine weitere Empfehlung: Aktualisieren Sie auf MySQL 5.5, damit Sie InnoDB für mehrere CPUs und mehrere Threads für Lese- / Schreib-E / A konfigurieren können.
Siehe meine früheren Beiträge zur Verwendung von MySQL 5.5 in Verbindung mit dem Zugriff auf mehrere CPUs für InnoDB
UPDATE 2012-09-06 14:56 EDT
Meine Methode zum Leeren des Abfragecaches ist ziemlich extrem, da sie zwischengespeicherte Daten überflutet und ein völlig anderes RAM-Segment bildet. Wie Sie in Ihrem Kommentar ausgeführt haben FLUSH QUERY CACHE(wie Sie vorgeschlagen haben) oder sogar RESET QUERY CACHEbesser wären. Zur Verdeutlichung, als ich "kein interner Mechanismus" sagte, meinte ich genau das. Die Defragmentierung ist erforderlich und muss manuell durchgeführt werden. Es müsste crontab'd werden .
Wenn Sie DML (INSERTs, UPDATEs, DELETEs) in InnoDB häufiger ausführen als in MyISAM, würde ich sagen, dass Sie den Abfrage-Cache insgesamt entfernen, was ich am Anfang gesagt habe.