Hey, I just happened upon your poll, so I'm sending you brief mail because I have a different opinion still :-) I'm also CCing the MySQL list, as I feel that more input on this might be a good thing - and it's worth some exposure anyway.
I believe there are two distinct measures that can be taken: * Ratio of selects that were returned from the cache against total server queries (caching ratio) * Ratio of selects that were served from cache against selects that were inserted into the cache (statement reuse ratio) The former gives an indication of how many queries were served from the cache against the total number of questions asked. It's a useful measure to see wether it's worth the effort to see if there's ways to rewrite queries or code so that more queries become cacheable. Given that https://dev.mysql.com/doc/refman/5.7/en/server-status-variables.html#statvar_Com_xxx explicitly states that queries served from cache do NOT increment com_select, I believe that calculation requires qcache_hits, qcache_inserts AND com_select. I'm not clear on wether qcache_not_cached augments com_select, though I would suspect it does. Even if this ratio is relatively low, it's not necessarily a problem - every query served from cache is a parse/exec saved. On multitenancy you could have a database that benefits hugely from the cache, and ten others that hardly use it, and that is not a problem as such. The latter, on the other hand, tells you how many of the queries that were inserted into the cache, are actually served from cache afterwards. This requires only qcache_hits and qcache_inserts; but it is a very good measure of wether your query cache is actually providing any benefit - THIS is the ratio that should be high - if it's close to 1, it may mean you spend more time inserting and clearing than you save by the occasional cache hit. So, my suggestion would be to certainly use the latter option for the check_mysql_health check; but it may be useful in some scenarios to have a separate check for the former, too. /johan -- What's tiny and yellow and very, very dangerous? A canary with the root password.
