Vor einigen Jahren (ja das stimmt wirklich) habe ich mal einen kurzen Blog-Post zum Thema MySQL Query-Cache geschrieben. Leider ist die Verwendung des Query-Cache nicht wirklich unumstritten und auch nicht in jeder Umgebung ein problemlösendes Mittel. Neben Fragmentierung des Caches und einigen Limitierungen bezüglich gecachter Operationen kann gerade die interne Pflege des Caches ein Problem sein. Ursache hierfür ist das bei Aktualisierung der Basistabellen auch alle sich darauf beziehenden Cache-Einträge gelöscht werden. Dies ist Aufwändig und führt in Umgebungen mit hoher Transaktionsdichte oft dazu, dass nahezu nie ein Ergebnis aus dem Cache kommt aber trotzdem alle Ergebnisse einer Select-Abfrage in den Cache gelegt und dort verwaltet werden.
Die spannenden Hints dafür sind SQL_CACHE und SQL_NO_CACHE mit denen sich das Verhalten des Query-Caches auf Basis von Einzelstatements steuern lässt.
Ein Beispiel:

SELECT /*! SQL_NO_CACHE */ product_id, product_name, product_price from products;

Mit diesem Hint kann man die Ablage des Ergebnisses im Cache verhindern und ggf. wirkungslose Caching-Last vom System nehmen. In die andere Richtung funktioniert das natürlich auch 🙂

Bernd Erk
Bernd Erk
CEO
Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startete er früher das wöchentliche Lexware-Backup, welches er nun endlich automatisiert hat. So investiert er seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinen beiden Söhnen und seiner Tochter.
Lies mehr von Bernd und triff unser Team