我的MySQL Query Cache查询慢不是一般的慢,而是刷新一个页面需要7秒左右了,这产无法接受的,但是我查看cpu使用正常,后来经过排查好像是热闹关键词的原因,下面来看我的解决办法.
进mysql:SHOW FULL PROCESSLIST;
Command多为Sleep,客户端过来的连接倒也正常,重复执行上述命令发现有些Command的状态为“Coping to tmp table”,果断打开my.cnf发现并无tmp_table_size的设置,MySQL环境是使用yum安装,这也是为什么要编译MySQL的缘故.
- mysql> SHOW VARIABLES LIKE 'tmp_table_size';
- +
- | Variable_name | Value |
- +
- | tmp_table_size | 16777216 |
- +
- 1 row in set (0.00 sec)
-
- mysql> SHOW VARIABLES LIKE 'max_heap_table_size';
- +
- | Variable_name | Value |
- +
- | max_heap_table_size | 16777216 |
- +
- 1 row in set (0.00 sec)
这样一看这两个设置的值并不低,看来并不是tmp table导致的问题,不过为了确保没问题,在my.cnf中增加:
tmpdir=/tmp
tmp_table_size=1073741824
重启MySQL,问题依旧,看来设置足够,还是其他的原因,打开下mysql-log,发现被查询的那个表正在不停地插入数据,按照这个网站的Pv数量可以判断有人在频繁使用检索功能,这个功能目前并没有配置sphinx全文索引,而是直接读取数据库,并且会实时统计用户输入的关键词,不过被人为的频繁插入新数据中,会导致mysql query cache在使用过程中不停地重建,也就是这个原因导致了mysqld的CPU使用率居高不下,看来这样实时的排序还是应该交给Memcache或者Redis去执行,并且再次验证GROUP.
mysql的query_cache认识的误区
下面我们通过实验及源码具体分析,首先,我们先试验一下.
首先,我们看一下mysql query_cache的状态,我们可以确认,mysql的query_cache功能是打开的.
其次,我们看一下状态,因为这个db是新的db,所以hits，inset都为0,现在我们执行一条select语句.
可以看到，执行一条select后，现在的qcache状态为，insert+1，这样我们就可以推断出，现在刚才那条select语句已经加入了qcache中。那我们现在再将刚才那条sql前面加上空格，看看会怎样呢？
请注意，这条sql，比刚才那条sql前面多了一个空格。
按照网上的理论，这条sql应该会作为另一个键而插入另一个cache，不会复用先前的cache,但结果呢？
我们可以看到，hits变为了1，而inserts根本没变，这就说明了，这条在前面加了空格的query命中了没有空格的query的结果集。从这，我们就可以得出结论，网上先前流传的说法，是不严谨的。
Query Cache 如何处理子查询的？
这是我遇到的最为常见的一个问题。其实 Query Cache 是以客户端请求提交的 Query 为对象来处理的，只要客户端请求的是一个 Query，无论这个 Query 是一个简单的单表查询还是多表 Join，亦或者是带有子查询的复杂 SQL，都被当作成一个 Query，不会被分拆成多个 Query 来进行 Cache。所以，存在子查询的复杂 Query 也只会产生一个Cache对象，子查询不会产生单独的Cache内容。UNION[ALL] 类型的语句也同样如此。
Query Cache 是以 block 的方式存储的数据块吗？
不是，Query Cache 中缓存的内容仅仅只包含该 Query 所需要的结果数据，是结果集。当然，并不仅仅只是结果数据，还包含与该结果相关的其他信息，比如产生该 Cache 的客户端连接的字符集，数据的字符集，客户端连接的 Default Database等。
Query Cache 为什么效率会非常高，即使所有数据都可以 Cache 进内存的情况下，有些时候也不如使用 Query Cache 的效率高？
Query Cache 的查找，是在 MySQL 接受到客户端请求后在对 Query 进行权限验证之后，SQL 解析之前。也就是说，当 MySQL 接受到客户端的SQL后，仅仅只需要对其进行相应的权限验证后就会通过 Query Cache 来查找结果，甚至都不需要经过 Optimizer 模块进行执行计划的分析优化，更不许要发生任何存储引擎的交互，减少了大量的磁盘 IO 和 CPU 运算，所以效率非常高。
客户端提交的 SQL 语句大小写对 Query Cache 有影响吗？
有，由于 Query Cache 在内存中是以 HASH 结构来进行映射，HASH 算法基础就是组成 SQL 语句的字符，所以必须要整个 SQL 语句在字符级别完全一致，才能在 Query Cache 中命中，即使多一个空格也不行。
一个 SQL 语句在 Query Cache 中的内容，在什么情况下会失效？
为了保证 Query Cache 中的内容与是实际数据绝对一致，当表中的数据有任何变化，包括新增，修改，删除等，都会使所有引用到该表的 SQL 的 Query Cache 失效。
为什么我的系统在开启了 Query Cache 之后整体性能反而下降了？
当开启了 Query Cache 之后，尤其是当我们的 query_cache_type 参数设置为 1 以后，MySQL 会对每个 SELECT 语句都进行 Query Cache 查找，查找操作虽然比较简单，但仍然也是要消耗一些 CPU 运算资源的。而由于 Query Cache 的失效机制的特性，可能由于表上的数据变化比较频繁，大量的 Query Cache 频繁的被失效，所以 Query Cache 的命中率就可能比较低下。所以有些场景下，Query Cache 不仅不能提高效率，反而可能造成负面影响。
如何确认一个系统的 Query Cache 的运行是否健康，命中率如何，设置量是否足够？
MySQL 提供了一系列的 Global Status 来记录 Query Cache 的当前状态，具体如下：
•Qcache_free_blocks：目前还处于空闲状态的 Query Cache 中内存 Block 数目
•Qcache_free_memory：目前还处于空闲状态的 Query Cache 内存总量
•Qcache_hits：Query Cache 命中次数
•Qcache_inserts：向 Query Cache 中插入新的 Query Cache 的次数，也就是没有命中的次数
•Qcache_lowmem_prunes：当 Query Cache 内存容量不够，需要从中删除老的 Query Cache 以给新的 Cache 对象使用的次数
•Qcache_not_cached：没有被 Cache 的 SQL 数，包括无法被 Cache 的 SQL 以及由于 query_cache_type 设置的不会被 Cache 的 SQL
•Qcache_queries_in_cache：目前在 Query Cache 中的 SQL 数量
•Qcache_total_blocks：Query Cache 中总的 Block 数量
可以根据这几个状态计算出 Cache 命中率,计算出 Query Cache 大小设置是否足够,总的来说,我个人不建议将 Query Cache 的大小设置超过256MB,这也是业界比较常用的做法.
MySQL Cluster 是否可以使用 Query Cache？
其实在我们的生产环境中也没有使用 MySQL Cluster,所以我也没有在 MySQL Cluster 环境中使用 Query Cache 的实际经验,只是 MySQL 文档中说明确实可以在 MySQL Cluster 中使用 Query Cache,从 MySQL Cluster 的原理来分析,也觉得应该可以使用,毕竟 SQL 节点和数据节点比较独立,各司其职,只是 Cache 的失效机制会要稍微复杂一点. |
