Using a query cache also has some implications for your code. For example if you want to put a read lock on a table you probably need to flush the table from the cache because the cache itself doesn't hold locks. Keith
> Hi Mark, > > >> Does the MySQL query cache actually work? I have heard various things >> to the contrary, but haven't actually used it in production, so I >> don't know for certain. >> > > It depends. The query cache increases the amount of work that has to > be done - reads have to check the cache first and update it after a > miss, and writes have to check and invalidate the cache if necessary. > So there is some overhead there, and obviously the query cache won't > improve the data transfer time back to your app. > > The queries that work best with the cache are ones that are relatively > expensive to generate, but where the result set's small - like > aggregate queries. So it really depends on what you're doing. > > You can check your cache hit rate to get a benchmark of how effective > it is by looking at the status variables: Qcache_hits / (Qcache_hits + > Com_select) > > > Kind regards, > James McGlinn > __________________________________ > CTO > Eventfinder Limited > Suite 106, Heards Building > 2 Ruskin Street, Parnell, Auckland 1052 > Phone: +649 365 2342 > Mobile: +6421 633 234 > > [EMAIL PROTECTED] | www.eventfinder.co.nz > > > > > > --~--~---------~--~----~------------~-------~--~----~ NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
