

Caching could be the last thing you want to do - desigooner
http://www.mysqlperformanceblog.com/2010/07/24/caching-could-be-the-last-thing-you-want-to-do/

======
boyter
He does have a good point which is that caching when you are running many
unoptimised queries is hiding the underlying problem. That said there isnt too
much to see here other then dont rely on cache to save you and optimise other
stuff first since cache might end up hiding the underlying problem making it
hard to fix when you do need to.

------
mmt
_In terms of future-proofing design, many applications are better off keeping
it simple and (at least initially) refusing the temptation to try and solve
some problems “like the big guys do”._

To me, this is the most important argument against knee-jerk reliance on
memcache, sharding, (ironically) MySQL, NoSQL, or what happens to be the new
fashion[1].

Understandably, buckling down and squeezing more out of the existing, tried
and true, technology, is neither sexy nor exciting. However, you're no"big
guy" yet, and, once you are, you'll kow that a bit of early tedium[2] can pay
off.

[1] Like with clothing fashion, novelty is periodic, rather than monotonic.

[2] e.g. Google's early "cork board" servers could only be sexy in retrospect

------
gaius
_Do your queries SELECT, only to use subset of columns? Or do you extract many
rows, only to use a subset?_

All the database optimization in the world won't help you if your developers
only know how to do

    
    
        SELECT * FROM MYTABLE;

~~~
spudlyo
Sometimes it's not that big of a deal. The idea is if you specify only the
columns you need, sometimes those columns can be satisfied directly from the
index (what's known as a covering index) and you don't need to seek around to
the various data pages to pull the rest of the columns.

InnoDB though uses a clustered indexing scheme, where the rest of the columns
are stored in the leaf nodes, so if you query by primary key, all the data is
right there -- no extra seeking.

Anyway, obviously it's better to only ask for what you need, but it's not the
stupidest thing in the world to SELECT with wildcard.

~~~
gaius
Well, also that you're not physically moving data you don't need across the
connection.

I have literally seen "programmers" simply select like that and filter out the
rows they want, or sort the entire table (and then filter out the rows), in
their own code. Madness.

------
knieveltech
Sorry, I stopped reading at six sigma.

~~~
JoachimSchipper
In this particular case, he could have written "reliably good performance is
important". Which _is_ a sensible idea, buzzword or no.

