MySQL Forums
Forum List  »  Optimizer & Parser

Re: Query cache
Posted by: Toa Sty
Date: November 02, 2006 03:11AM

Michael Dar Wrote:
-------------------------------------------------------
> Hmm, that way your DB will not be totally
> normalized.

It's true. Depending on your app sometimes it's worth it though. I wouldn't suggest doing it unless you really need to; normalised schemas are pretty good from a performance POV in many cases.


> Why don't you run another select just after update
> and restore it back to cache?

Well, potentially thousands of queries could be invalidated by the one update, and it can be hard to know which they were, so this would only work when you're interested in a particular select that you need to be fast the next time you call it, for some reason. In most cases it's better to let the cache fill normally I think.

> It's also working arround but again it depends on
> volume of selects and updates your application
> performs. Naturally, if updates don't have high
> capacity volume then it may fit you.

Agreed. The vertical partitioning suggestion is only worth it if you have a case were you need super-fast querying (i.e. a good query cache hit ratio) on your data, and the parts of your data that don't change often are the parts that you mostly query on. Having said this, horiz partitioning can also help in this way sometimes, but it's going to depend on your data.

All these things are workarounds for cases where you really need query cache hits and are willing to compromise schema and general complexity. They're certainly not things that you should do unless you know you need to :)

Toasty

-----------------------------------------
email: 'toasty'*3 at gmail

Options: ReplyQuote


Subject
Views
Written By
Posted
2808
October 31, 2006 01:32PM
2020
October 31, 2006 04:12PM
1966
November 01, 2006 06:27AM
2000
November 01, 2006 12:25PM
Re: Query cache
2083
November 02, 2006 03:11AM


Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.