一个64位的linux操作系统，mysql是5.1,query_cache_size大约设置多少合适，设置标准是什么。

Question

一个64位的linux操作系统，mysql是5.1,query_cache_size大约设置多少合适，设置标准是什么。

Answer 1

这个cache最好不要用，query_cache_type建议设置成2。 对需要的query用显式的命令来用cache。 你的内存多大？

Answer 2

QueryCache 之后所带来的负面影响：
a) Query 语句的hash 运算以及hash 查找资源消耗。当我们使用Query Cache 之后，每条SELECT
类型的Query 在到达MySQL 之后，都需要进行一个hash 运算然后查找是否存在该Query 的
Cache，虽然这个hash 运算的算法可能已经非常高效了，hash 查找的过程也已经足够的优化
了，对于一条Query 来说消耗的资源确实是非常非常的少，但是当我们每秒都有上千甚至几千
条Query 的时候，我们就不能对产生的CPU 的消耗完全忽视了。
b) Query Cache 的失效问题。如果我们的表变更比较频繁，则会造成Query Cache 的失效率非常
高。这里的表变更不仅仅指表中数据的变更，还包括结构或者索引等的任何变更。也就是说我
们每次缓存到Query Cache 中的Cache 数据可能在刚存入后很快就会因为表中的数据被改变而被
清除，然后新的相同Query 进来之后无法使用到之前的Cache。
c) Query Cache 中缓存的是Result Set ，而不是数据页，也就是说，存在同一条记录被Cache 多
次的可能性存在。从而造成内存资源的过渡消耗。当然，可能有人会说我们可以限定Query
Cache 的大小啊。是的，我们确实可以限定Query Cache 的大小，但是这样，Query Cache 就很
容易造成因为内存不足而被换出，造成命中率的下降。

Answer 3

虽然Query Cache 的使用会存在一些负面影响，但是我们也应该相信其存在是必定有一定价值。我
们完全不用因为Query Cache 的上面三个负面影响就完全失去对Query Cache 的信心。只要我们理解了
Query Cache 的实现原理，那么我们就完全可以通过一定的手段在使用Query Cache 的时候扬长避短，重
发发挥其优势，并有效的避开其劣势。
首先，我们需要根据Query Cache 失效机制来判断哪些表适合使用Query 哪些表不适合。由于Query
Cache 的失效主要是因为Query 所依赖的Table 的数据发生了变化，造成Query 的Result Set 可能已经
有所改变而造成相关的Query Cache 全部失效，那么我们就应该避免在查询变化频繁的Table 的Query 上
使用，而应该在那些查询变化频率较小的Table 的Query 上面使用。MySQL 中针对Query Cache 有两个专
用的SQL Hint（提示）：SQL_NO_CACHE 和SQL_CACHE，分别代表强制不使用Query Cache 和强制使用
Query Cache。我们完全可以利用这两个SQL Hint，让MySQL 知道我们希望哪些SQL 使用Query Cache 而
哪些SQL 就不要使用了。这样不仅可以让变化频繁Table 的Query 浪费Query Cache 的内存，同时还可以
减少Query Cache 的检测量。
其次，对于那些变化非常小，大部分时候都是静态的数据，我们可以添加SQL_CACHE 的SQL Hint，
强制MySQL 使用Query Cache，从而提高该表的查询性能。
最后，有些SQL 的Result Set 很大，如果使用Query Cache 很容易造成Cache 内存的不足，或者将
之前一些老的Cache 冲刷出去。对于这一类Query 我们有两种方法可以解决，一是使用SQL_NO_CACHE 参
数来强制他不使用Query Cache 而每次都直接从实际数据中去查找， 另一种方法是通过设定
“query_cache_limit”参数值来控制Query Cache 中所Cache 的最大Result Set ，系统默认为
1M（1048576）。当某个Query 的Result Set 大于“query_cache_limit”所设定的值的时候，Query
Cache 是不会Cache 这个Query 的。

Answer 4

以上zz MySQL性能调优与架构设计