Michael Schröpl: Caching von Suchergebnissen zwecks Navigation (MySQL)

Beitrag lesen

Hi Marc,

Ist MySQL so smart das Resultat der ersten Query der Suchanfrage zu Cachen, so dass bei Aufruf der gleichen Anfrage (nur mit anderen LIMIT-Werten) nicht wieder erneut die DB befragt wird?

woher soll mySQL wissen, daß sich der Inhalt der Tabelle zwischenzeitlich nicht geändert hat?

Oder lohnt sich der Einsatz einer temporären Tabelle um z.B. die Keys aus dem ersten Result zu speichern, also das Caching selbst zu bauen?

Ich denke, nein.

Wenn Deine Tabelle gut geindext ist, dann besteht der wesentliche Teil des Aufwandes darin, auf diesen Indexbaum zuzugreifen.
Die Daten dieses Zugriffsbaums brauchst Du bei zwei "verwandten" Suchanfragen wiederum nicht vollständig, sondern jeweils nur den Abstiegspfad innerhalb dieses Baums, also eine logarithmisch kleine Teilmenge.
Diese kann das RDBMS sicherlich bequem cachen - überprüfe ggf. in der mySQL-Konfiguration, wie dort entsprechende Puffergrößen für Indexzugriffe eingestellt sind (ich rate mal, daß diese Parameter tabellentypbezogen ausfallen könnten, also spezifisch für myISAM etc.).

Oder gibt es andere Lösungsansätze ?

Bei solchen Fragen ist mein Vertrauen in die Umsetzung LRU-ähnlicher Algorithmen durch die Kombination aus RDBMS und Betriebssystem hoch genug, um mir hier keine eigenen Gedanken machen zu wollen. Diese stecke ich lieber in meine CREATE INDEX-Statements ...

Viele Grüße
      Michael

--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
 => http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.