temporäre Tabelle bei MySQL

[Rolf b]

Ob man einen Cache im Filesystem hält, in einer DB-Row (wie es der OP beschrieben hat) oder auf einem eigenen Cache-Server, hängt sicherlich vom Anwendungsfall ab.

Hat man nur einen Applicationserver (möglicherweise sogar einen, auf dem Web+App zusammenfallen), ist das Filesystem die beste Wahl. Die serialisierten Ergebnisse im SQL Server zu speichern ist eigentlich eine unnötige Belastung für ihn. Dem Einwand mit zu vielen Dateien kann man durch scharfes Überlegen begegnen, welche Queries denn so gecached werden sollen. Oder man verteilt es in mehrere Verzeichnisse und hat in einem Verzeichnis nur die Ergebnisse einer Query (in einer Datei je Parametersatz).

Hat man einen Server-Cluster, ist Filesystem ungünstig, weil dann jeder Server für sich cached. Dann ist die Cache-Table mit serialisierten Abfrageergebnissen ein Cache-Server für arme Leute und bringt dadurch etwas, dass die komplexen Abfragewege der eigentlichen Query eingespart werden. Aber eine SQL Last ist es immer noch. Ein richtiger Cache-Server (wo die Daten im RAM oder als Dateien im Filesystem gehalten werden) würde die DB stärker entlasten. Aber das setzt eine entsprechend große Farm voraus, sonst lohnt das nicht.

WENN Deine Daten so geartet sind, dass ein Caching mit einem Tag Verfallsfrist machbar ist, dann hast Du auch noch eine andere Möglichkeit: prepared data. Du kannst die Tabellen, die deine "langsamen" Queries abfragen, ggf. in andere Tabellen transformieren. Diese anderen Tabellen könnten dann Redundanzen enthalten, oder bereits vorbereitete Zwischensummen haben - was man tun kann hängt sehr vom konkreten Fall ab. Wenn das Ergebnis der Transformation darin besteht, dass die langsame Query nicht mehr 500ms, sondern 5ms braucht, kann sich die Sache lohnen. Die prepared data Tabellen könntest Du dann jeden Morgen um 5 Uhr (oder so) einmal befüllen. Ist nur so ein Gedanke...

Rolf