When a query goes from 18 to 10 seconds, or similar times, it is likely
because of caching at the MySQL or OS/disk level, not query caching. The
first time, the info had to be found on the disk and read, which is
relatively slow. After that it's in memory and can be accessed more quickly
in the future, though it still has to be analyzed/sifted/ordered.
When a query goes form 18 seconds to more like 0.01 seconds, it's because of
query caching. The data is not consulted; instead the query's precise
answer is already in memory in the right order, so it is sent nearly
Query caching can give an enormous speed boost for near-static databases;
for dbs that change a lot, its impact (positive or negative) is generally
minimal. There is some minor overhead associated with it.
On 8/23/06, Ratheesh K J <ratheesh.kj@stripped> wrote:
> Hello all,
> I wanted to know why a select query takes ,say, 18 sec to execute the
> first time I execute it and then for every successive execution it takes,
> say, 10 sec.
> I have disabled Query Caching on the server. If its not Query Caching then
> what else is causing this variation in exec time?
> 1) Also i would like to know something about table caching (what exactly
> gets cached here?) and its advantages
> 2) What is an optimal join order. Should it be a smaller result joined
> with a bigger one or vice-versa, Or how does MySQL do it?
> Ratheesh Bhat K J