我正在调整我的VPS [360MB安装程序]上的MySQL查询caching。 当我开始时，它被设置为32MB，我得到了一个不平凡的数量的qcache_lowmem_prunes。 我添加了一个cronjob来定期运行FLUSH QUERY CACHE，这有助于，但还不够。 我一直在逐渐扩大它，但即使在80MB（我暂时从php-cgi中拿走了一些内存），我仍然看到了lowmem李子。
OTOH，我只有大约50％的命中率[即Qcache_hits大约是Qcache_hits + Com_select的一半]。 我强烈怀疑我的许多查询是一次性查询，因此不应该被caching。 我想识别它们，并用SQL_NO_CACHE标记它们。
任何build议，一个简单的方法来做到这一点？
也有可能我的一些查询没有被caching，因为表格已经改变了，尽pipe我不认为基于粗略的心理模型，情况就是这样。 至less，对于大多数查询来说结果应该是一致的; 我使用的是InnoDB，所以我的理解是随机的UPDATE不一定会使所有的SELECT失效。 它是否正确？
我不明白你为什么要刷新caching。 它照顾自己，并没有性能上的好处（我见过），定期冲洗它。 50％的caching命中率实际上相当惊人。
表中任何行的任何更新都将使使用该表的所有查询无效。 这意味着任何join到它的查询被清除。 结果是否受到影响并不重要。
我build议使用像memcached这样的caching解决scheme，而对caching内容和数据过期的细节进行更好的控制。
如果看到性能问题，最好删除与查询caching关联的内存，并将innodb_buffer_pool和innodb_additional_mem_pool_size合并。
http://dev.mysql.com/doc/refman/5.0/en/innodb-configuration.html
另外，你应该看看在MySQL调谐器： https ： //launchpad.net/mysqltuner/
您可以创buildMySQL触发器，以便即时分析包含请求的请求，并使用query_cache var重写它。
这将消耗更多的CPU，但避免查看软件的来源。