Most likely it's the OS cache caching all those disk
segments in memory. Also in InnoDB, MySQL uses the
Buffer Pool Size to cache data pages in addition to
the OS cache.

If you're running ona Windows machine, you can easily
tell what's going on by opening up Performance Monitor
and watching Pages/Sec and Disk Reads/Sec. If these
two counters were low in the subsequent queries (and
they should unless you're tight on physical memory),
then the data is cached.




--- Bob O'Neill <[EMAIL PROTECTED]> wrote:
> Hello.  I am wondering why some of my queries are
> slow on the first run, but
> speedy on subsequent runs.  They are not being query
> cached, as I have
> query_cache_type set to DEMAND.  Is it something as
> simple as pulling the
> data into RAM from disk, or is there something else
> going on?  Here's a
> simple example:
> 
> mysql> select count(*) from foo;
> +----------+
> | count(*) |
> +----------+
> |  1374817 |
> +----------+
> 1 row in set (3.60 sec)
> 
> mysql> select count(*) from foo;
> +----------+
> | count(*) |
> +----------+
> |  1374817 |
> +----------+
> 1 row in set (0.92 sec)
> 
> mysql> show variables like 'query_cache_type';
> +------------------+--------+
> | Variable_name    | Value  |
> +------------------+--------+
> | query_cache_type | DEMAND |
> +------------------+--------+
> 1 row in set (0.00 sec)
> 
> I am running MySQL 4.1.10 with InnoDB on RHEL 2.1
> (kernel
> 2.4.9-e.49enterprise). Binaries are Linux x86 glibc
> static gcc RPMs from
> mysql.com.
> 
> Thanks,
> -Bob
> 
> 
> -- 
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:   
>
http://lists.mysql.com/[EMAIL PROTECTED]
> 
> 

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to