healthy ratio of Qcache_hits to Qcache_inserts?

[Jeff Ambrosino]

I've just reworked some of my SQL queries to hopefully improve query cacheing... mainly I've removed alot of variability in a set of queries so that they should be only a small number of unique SQL SELECT statements spread across many thousands of queries.

Here are some preliminary results I'm seeing:

mysql> show status like 'Com_sel%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Com_select | 27659 |
+---------------+-------+
1 row in set (0.00 sec)

mysql> show status like '%cache%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Binlog_cache_disk_use | 0 |
| Binlog_cache_use | 0 |
| Qcache_free_blocks | 53 |
| Qcache_free_memory | 66949568 |
| Qcache_hits | 22471 |
| Qcache_inserts | 21450 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 6249 |
| Qcache_queries_in_cache | 54 |
| Qcache_total_blocks | 175 |
| Threads_cached | 1 |
+-------------------------+----------+

So, it seems that I have a high "Qcache_hits" to "Com_select" ratio... but what I don't understand is the "Qcache_inserts" variable. The ratio of Qcache_hits to Qcache_inserts is only slightly more than 1. Is this healthy? Should it be the case that if a SELECT is served from the cache, then there's no cache-insert?

Could someone clarify what Qcache_insert means? Is it that the result of a SELECT was actually put in the cache? And a cache insert doesn't happen for a query that was served from the cache in the first place? (a Qcache_hit).

thanks for any clarification.

JB