MySQL 查询缓存命中率是什么?哪些因素影响查询的命中率?

MySQL 查询缓存命中率是什么?哪些因素影响查询的命中率?,第1张

影响查询命中率高低的四个因素:1.一模一样的SQL重复执行的次数 ;2.查询语句结果集有多少缓存在query_cache_size中;3.有多少查询语句结果集缓存,因元数据发生变化而不得不从缓存中踢出 ;4.查询缓存能存多少结果集,那么就由query_cache_size配置信息和查询结果集的大小 有关系;

mysql 开启查询缓存可以有两种方法来开启一种是使用set命令来进行开启,另一种是直接修改my.ini文件来直接设置都是非常的简单的哦。

开启缓存,设置缓存大小,具体实施如下:

windows下是my.ini,linux下是my.cnf

在配置文件的最后追加上:

需要重启mysql生效;

b) 开启缓存,两种方式:

a)使用mysql命令:

如果报错:

Query cache is disabledrestart the server with query_cache_type=1 to enable it,还是老老实实的该配置文件,然后重启吧,原因如下:

查看是否设置成功

show variables like "%query_cache%" 查看是否设置成功:

当然如果你的数据表有更新怎么办,没关系mysql默认会和这个表有关系的缓存删掉,下次查询的时候会直接读表然后再缓存

下面是一个简单的例子:

以上的相关内容就是对mysql缓存查询和设置的介绍,望你能有所收获。

一般,我们会把 query_cache_type 设置为 ON,默认情况下应该是ON

query_cache_type有3个值 0代表关闭查询缓存OFF,1代表开启ON,2(DEMAND)代表当sql语句中有SQL_CACHE关键词时才缓存,如:

这样 当我们执行 select id,name from tableName这样就会用到查询缓存。

①在 query_cache_type 打开的情况下,如果你不想使用缓存,需要指明

select sql_no_cache id,name from tableName

②当sql中用到mysql函数,也不会缓存

当然也可以禁用查询缓存: mysql>set session query_cache_type=off

上面的显示,表示设置查询缓存是可用的。

表示查询缓存大小,也就是分配内存大小给查询缓存,如果你分配大小为0,

那么 第一步 和 第二步 起不到作用,还是没有任何效果。

上面是 mysql6.0设置默认的,之前的版本好像默认是0的,那么就要自己设置下。

设置

这里是设置1M左右,900多K。

再次查看下:

显示我们设置新的大小,表示设置成功。

例如: 如果查询结果很大, 也缓存????这个明显是不可能的。

MySql 可以设置一个最大的缓存值,当你查询缓存数结果数据超过这个值就不会

进行缓存。缺省为1M,也就是超过了1M查询结果就不会缓存。

这个是默认的数值,如果需要修改,就像设置缓存大小一样设置,使用set

重新指定大小。

好了,通过4个步骤就可以 打开了查询缓存,具体值的大小和查询的方式 这个因不同

的情况来指定了。

mysql查询缓存相关变量

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 数量

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

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

的情况进行递增

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

query_cache_min_res_unit的配置是一柄”双刃剑”,默认是4KB,设置值大对大数据查询有好处,但如果你的查询都是小数据 查询,就容易造成内存碎片和浪费。

查询缓存碎片率 = Qcache_free_blocks / Qcache_total_blocks * 100%

如果查询缓存碎片率超过20%,可以用FLUSH QUERY CACHE整理缓存碎片,或者试试减小query_cache_min_res_unit,如果你的查询都是小数据量的话。

查询缓存利用率 = (query_cache_size - Qcache_free_memory) / query_cache_size * 100%

查询缓存利用率在25%以下的话说明query_cache_size设置的过大,可适当减小查询缓存利用率在80%以上而且 Qcache_lowmem_prunes >50的话说明query_cache_size可能有点小,要不就是碎片太多。

查询缓存命中率 = (Qcache_hits - Qcache_inserts) / Qcache_hits * 100%

示例服务器 查询缓存碎片率 = 20.46%,查询缓存利用率 = 62.26%,查询缓存命中率 = 1.94%,命中率很差,可能写 *** 作比较频繁吧,而且可能有些碎片。

查询缓存可以看做是SQL文本和查询结果的映射。如果第二次查询的SQL和第一次查询的SQL完全相同(注意必须是完全相同,即使多一个空格或者大小写不同都认为不同)且开启了查询缓存,那么第二次查询就直接从查询缓存中取结果,可以通过下面的SQL来查看缓存命中次数(是个累加值):

另外即使完全相同的SQL,如果使用不同的字符集、不同的协议等也会被认为是不同的查询而分别进行缓存。

在表的结构或数据发生改变时,查询缓存中的数据不再有效。有这些INSERT、UPDATE、 DELETE、TRUNCATE、ALTER TABLE、DROP TABLE或DROP DATABASE会导致缓存数据失效。所以查询缓存适合有大量相同查询的应用,不适合有大量数据更新的应用。

可以使用下面三个SQL来清理查询缓存:

1、FLUSH QUERY CACHE// 清理查询缓存内存碎片。

2、RESET QUERY CACHE// 从查询缓存中移出所有查询。

3、FLUSH TABLES//关闭所有打开的表,同时该 *** 作将会清空查询缓存中的内容。

Query Cache是MySQL Server层的一个非常好的特性,对于小数据集或访问量非常集中的应用场景,有非常好的性能提升,但是Query Cache引入了一些新的问题,而且大部分场景下比较鸡肋,官方打算弃用了

参考:

https://www.cnblogs.com/wangzhuxing/p/5223881.html

https://www.cnblogs.com/lixiuran/archive/2014/03/08/3588654.html

其中很多人谈到了缓存命中率的问题,应用缓存的命中率取决于很多的因素:

1、应用场景

是OLTP还是OLAP应用,即使是OLTP,也要看访问的频度,一个极少被访问到的缓存等于没有什么效果。一般来说,互联网网站是非常适合缓存应用的场景。

2、缓存的粒度

毫无疑问,缓存的粒度越小,命中率就越高,对象缓存是目前缓存粒度最小的,因此被命中的几率更高。举个例子来说吧:你访问当前这个页面,浏览帖子,那么对于ORM来说,需要发送n条SQL,取各自帖子user的对象。很显然,如果这个user在其他帖子里面也跟贴了,那么在访问那个帖子的时候,就可以直接从缓存里面取这个user对象了。

3、架构的设计

架构的设计对于缓存命中率也有至关重要的影响。例如你应该如何去尽量避免缓存失效的问题,如何尽量提供频繁访问数据的缓存问题,这些都是考验架构师水平的地方。再举个例子来说,对于论坛,需要记录每个topic的浏览次数,所以每次有人访问这个topic,那么topic表就要update一次,这意味着什么呢?对于topic的对象缓存是无效的,每次访问都要更新缓存。那么可以想一些办法,例如增加一个中间变量记录点击次数,每累计一定的点击,才更新一次数据库,从而减低缓存失效的频率。

4、缓存的容量和缓存的有效期

缓存太小,造成频繁的LRU,也会降低命中率,缓存的有效期太短也会造成缓存命中率下降。

所以缓存命中率问题不能一概而论,一定说命中率很低或者命中率很高。但是如果你对于缓存的掌握很精通,有意识的去调整应用的架构,去分解缓存的粒度,总是会带来很高的命中率的。

这里我可以举一个实际的案例,JavaEye2.0网站在使用对象缓存之前,通过MySQL的监控工具进行观察,在连续24小时的平均每秒发送SQL条数超过了200条,在使用对象缓存之后,连续24小时的平均每秒发送SQL条数下降到了120条左右,几乎下降了一半。

考虑到很多SQL都是分页语句,关联查询,条件查询,集合 *** 作,都是不能被缓存的SQL,而真正能够被缓存的SQL只有根据主键查询对象和对象关联对象的查询。所以真正能够被缓存的SQL估计最多占所有SQL的60%。所以换算下来,应用缓存的命中率之高,已经相当惊人了。

不过这里要提醒的一点,有将近一半的SQL都被缓存,不意味着性能可以提升一倍。这是因为能够被缓存的都是按照主键查询单条记录的SQL,这些SQL本身即使发送到数据库,对数据库造成的压力也没有想像的那么大。真正对数据库造成庞大压力的正是那些没有索引的大表查询,和造成了全表扫描的关联查询,这些一旦涉及到全表扫描的查询,才是性能的真正杀手。当然了,不管怎么说,通过使用对象缓存,是毫无疑问可以大幅度降低数据库的负载压力的,有效提升web应用的性能的。

关于这一点,我再给出一组数据来加深大家的印象,通过使用 *** 作系统网络工具进行统计:

JavaEye网站web server的端口每秒数据流量是2MB;

JavaEye网站的MySQL数据库端口的每秒数据流量是1.2MB;

而网站的memcached的端口每秒的数据流量高达5MB


欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/7270259.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-03
下一篇 2023-04-03

发表评论

登录后才能评论

评论列表(0条)

保存