Planing table growth is of course typical mistake however designing schema without looking at the queries is the other one. The same data may need to be set out different ways depending on which queries you’re going to run, of course if high performance is the goal. A lot of queries out where fail because schemas based on Object relationships and ER diagrams can’t run them efficiently as is.

Regarding your comment about SQL_NO_CACHE you’re right however you should know what “quickly” really means. Is invalidation once per second is quickly ? Well it is if you only run same query once during this time but if you have 5.000 queries/sec and lets say 100 are same even with so frequent invalidation query cache may be worth it.

Also in many cases I see summary tables updated periodically rather than on every update.

But anyway you may often do better by caching stuff in memcache

One other quick tip:

If you do use a denormalized structure and use summary tables to store often-queried COUNTs and SUMs and the like, make sure you use SELECT SQL_NO_CACHE … FROM my_summary_table; to prevent the query cache from storing results for data that will be very quickly invalidated.

Cheers, and keep up the fantastic work, PeterZ!

Actually in this case I meant normalization, you’re however right for many very queries data denormalization is what actually help.

Let me give you an example. Assume someone has Denormalized schema of Cities which contains rows (City,State,Country,Population). Now to diplay list of cities one may do SELECT DISTINCT City from Cities, which is same as select City from Cities group by City. Now assume you want to display countries but you want to display top Countires by population you may do SELECT Country,sum(population) pop from Cities group by Country order by pop desc limit 10 but if you would normalize your data you could simply store list of countries separately and just add country population field to the table.

Is that a typo and you meant to say “denormalization”?