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 instantaneously. 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. Dan On 8/23/06, Ratheesh K J <[EMAIL PROTECTED]> 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? Thanks, Ratheesh Bhat K J
