> I have always found MySQL's query cache to be utterly useless.
>
> Think about it this way :
>
> It only works for tables that seldom change.
> It does not work for big tables (like the posts table of a forum)
> because the cache would have to be huge.
>
> So, the most frequent usage of MySQL's query cache is for dumb
> applications who use, for instance, PHP, store their configuration in
> MySQL, and reload it on each and every page with a SELECT * FROM
> configuration.
>
> In this case, you save the query time, but you don't save : the
> roundtrip between PHP and the database, extracting query results,
> building objects from them, time spent in ORMs, etc.
>
> A much better solution is to do your own caching, for instance
> using shared memory in the application server, and then you cache
> native language objects. You not only save the query time, but also
> all the time spent building those objects on every page load.
This was actually my original question. In my web page, I cache the
config, user preferences and other static material in session vars and
only rerun the function that fetches them if the app ever changes them
If you are clever about db fetches in this way and store as much stuff
in session vars (which is just like storing it in a memcached instance
really) is there much or even any benefit in running memcached?
