Mysql查询缓存碎片、缓存命中率及Nagios监控

Mysql 的优化方案,在互联网上可以查找到非常多资料,今天对Mysql缓存碎片和命中率作了详细了解,个人作了简单整理。

 

 

一、Mysql查询缓存碎片和缓存命中率。



  1. mysql> SHOW STATUS LIKE 'qcache%';
  2.         +-------------------------+-----------+
  3.         | Variable_name | Value |
  4.         +-------------------------+-----------+
  5.         | Qcache_free_blocks | 5 |
  6.         | Qcache_free_memory | 134176648 |
  7.         | Qcache_hits | 110 |
  8.         | Qcache_inserts | 245 |
  9.         | Qcache_lowmem_prunes | 0 |
  10.         | Qcache_not_cached | 7119 |
  11.         | Qcache_queries_in_cache | 9 |
  12.         | Qcache_total_blocks | 31 |
  13.         +-------------------------+-----------+
  14.         8 rows in set (0.01 sec)

MySQL 查询缓存变量

变量名

说明

Qcache_free_blocks

缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理,从而得到一个空闲块。

Qcache_free_memory

缓存中的空闲内存。

Qcache_hits

每次查询在缓存中命中时就增大。

Qcache_inserts

每次插入一个查询时就增大。命中次数除以插入次数就是不中比率;用 减去这个值就是命中率。在上面这个例子中,大约有 87% 的查询都在缓存中命中。

Qcache_lowmem_prunes

缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个数字在不断增长,就表示可能碎片非常严重,或者内存很少。(上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况)。

Qcache_not_cached

不适合进行缓存的查询的数量,通常是由于这些查询不是 SELECT 语句。

Qcache_queries_in_cache

当前缓存的查询(和响应)的数量。

Qcache_total_blocks

缓存中块的数量。




  1. mysql> SHOW VARIABLES LIKE '%query_cache%';
  2. +------------------------------+-----------+
  3. | Variable_name | Value |
  4. +------------------------------+-----------+
  5. | have_query_cache | YES |
  6. | query_cache_limit | 1048576 |
  7. | query_cache_min_res_unit | 4096 |
  8. | query_cache_size | 134217728 |
  9. | query_cache_type | ON |
  10. | query_cache_wlock_invalidate | OFF |
  11. +------------------------------+-----------+
  12. 6 rows in set (0.00 sec)

 

query_cache_min_res_unit    查询缓存分配的最小块的大小(字节)

query_alloc_block_size    为查询分析和执行过程中创建的对象分配的内存块大小
Qcache_free_blocks    代表内存自由块的多少,反映了内存碎片的情况

==========================
1)当查询进行的时候,Mysql把查询结果保存在qurey cache中,但如果要保存的结果比较大,超过query_cache_min_res_unit的值 ,这时候mysql将一边检索结果,一边进行保存结果,所以,有时候并不是把所有结果全部得到后再进行一次性保存,而是每次分配一块 query_cache_min_res_unit 大小的内存空间保存结果集,使用完后,接着再分配一个这样的块,如果还不不够,接着再分配一个块,依此类推,也就是说,有可能在一次查询中,mysql要 进行多次内存分配的操作。
2)内存碎片的产生。当一块分配的内存没有完全使用时,MySQL会把这块内存Trim掉,把没有使用的那部分归还以重 复利用。比如,第一次分配4KB,只用了3KB,剩1KB,第二次连续操作,分配4KB,用了2KB,剩2KB,这两次连续操作共剩下的 1KB+2KB=3KB,不足以做个一个内存单元分配, 这时候,内存碎片便产生了。
3)使用flush query cache,可以消除碎片

4)如果Qcache_free_blocks值过大,可能是query_cache_min_res_unit值过大,应该调小些
5query_cache_min_res_unit的估计值:(query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache

 

检查查询缓存使用情况

检查是否从查询缓存中受益的最简单的办法就是检查缓存命中率

当服务器收到SELECT 语句的时候,Qcache_hits Com_select 这两个变量会根据查询缓存

的情况进行递增

查询缓存命中率的计算公式是:Qcache_hits/(Qcache_hits + Com_select)

mysql> show status like '%Com_select%';

+---------------+-------+

| Variable_name | Value |

+---------------+-------+

| Com_select    | 1     |

+---------------+-------+

1 row in set (0.00 sec)

 

此时的查询缓存命中率:3/3+1=75%;由于个人的测试数据库,查询较少,更行更少,命中率颇高。

 

http://blog.chinaunix.net/uid-25266990-id-3426963.html

原文地址:https://www.cnblogs.com/Alight/p/4187850.html