I missed part of the initial discussion so sorry if this isn't quite what
you're looking for, but if you're talking about the query cache (the one
that caches the exact query and the exact results), this output can be
useful:
mysql> show status like "Q%";
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 1 |
| Qcache_free_memory | 33535648 |
| Qcache_hits | 2 |
| Qcache_inserts | 2 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 0 |
| Qcache_queries_in_cache | 2 |
| Qcache_total_blocks | 6 |
| Questions | 362 |
+-------------------------+----------+
9 rows in set (0.00 sec)
From here you can watch in real time for Qcache_hits. "Questions" is the
total number of queries. Indeed, LIMIT queries are cached, but just the
part that was returned.
If the query is the slightest bit different when run again, or if any of
the underlying tables have been written to, the query cache will be
ignored. But the data itself will most likely be in memory the next time
around so it will be faster than the first run anyways.
Just some food for thought.
Cheers,
Jonathan Field
On Sun, 2 Apr 2006, Perrin Harkins wrote:
On Mon, 2006-04-03 at 10:28 +0800, Foo Ji-Haw wrote:
Perrin Harkins wrote:
Jeff wrote:
Your application simply uses approach (b) and MySQL does the rest
automatically. So if you
Have you tried this? I was under the impression that MySQL would just
stop when it finds enough row to satisfy LIMIT, so it wouldn't cache
the whole result set.
I have, and I can verify that MySQL does some kind of internal
'caching', so that the next limit call is very fast.
How do you know it isn't just the operating system caching the disk
fetches? The docs certainly make it sound like a query cached with
LIMIT will not be useful when different LIMIT values are applied.
- Perrin
