243
文章
15
说说
411
评论
297066
访问

个人博客网站:prettywordpress.com(吃饭用大碗的程序猿)

最新评论
qq_avatar
2年前,”四五设计网”在《如何使用百度云CDN优化wordpress速度》
说:来学习一下,应该用得上
qq_avatar
2年前,” ”在《友情链接》
说:像不能用了更新地址为 https://aba.pet/wp-content/uploads/2022/05/favicon-1.gif
qq_avatar
3年前,”Alex”在《终于找到拖慢网站的罪魁祸首》
说:优化这么快,你有想过我们的感觉?
qq_avatar
3年前,”ヘル”在《码农=新生代农民工》
说:打卡@[huaixiao]
qq_avatar
3年前,”肋巴骨”在《Win10系统桌面一直闪屏自动刷新怎么办》
说:不错啊,这是谁写的教程,真棒
A+

MySQL如何开启Query Cache

标签:   最后编辑:2021年8月14日

带来的弊端

mysql服务器默认是关闭query_chache的,因为开启query_cache也是有代价的,会带来以下的额外消耗:

  1. 读查询开始之前必须检查是否命中缓存。
  2. 如果读查询可以缓存,那么执行完之后会写入缓存。
  3. 当向某个表写入数据的时候,必须将这个表所有的缓存设置为失效,如果缓存空间很大,则消耗也会很大,可能使系统僵死一段时间,因为这个操作是靠全局锁操作来保护的。
    对InnoDB表,当修改一个表时,设置了缓存失效,但是多版本特性会暂时将这修改对其他事务屏蔽,在这个事务提交之前,所有查询都无法使用缓存,直到这个事务被提交,所以长时间的事务,会大大降低查询缓存的命中
    一个表可以被许多类型的语句更改,例如INSERTUPDATEDELETETRUNCATEALTER TABLEDROP TABLEDROP DATABASE
    对于InnoDB而言,事物的一些特性还会限制查询缓存的使用。当在事物A中修改了B表时,因为在事物提交之前,对B表的修改对其他的事物而言是不可见的。为了保证缓存结果的正确性,InnoDB采取的措施让所有涉及到该B表的查询在事物A提交之前是不可缓存的。如果A事物长时间运行,会严重影响查询缓存的命中率
    查询缓存的空间不要设置的太大。
    因为查询缓存是靠一个全局锁操作保护的,如果查询缓存配置的内存比较大且里面存放了大量的查询结果,当查询缓存失效的时候,会长时间的持有这个全局锁。因为查询缓存的命中检测操作以及缓存失效检测也都依赖这个全局锁,所以可能会导致系统僵死的情况

    开启query_cache

    看了上面的提示之后你就能确定自己需不需要开启MySQL的query cache了。

  4. 查看是否使用通过下面SQL执行
    SHOW VARIABLES LIKE 'have_query_cache';
  5. 首先通过下面的SQL查询query_cache的设置情况
    SHOW STATUS LIKE 'Qcache%';
  6. 如发现结果中query_cache_size =0,则表示没有开启query cache设置。

    在 my.ini中,设置
    query_cache_size=128M
    query_cache_type=1

    常用命令

    show status like ‘%Qcache%’;

    参数讲解:

    • Qcache_free_blocks:表示查询缓存中目前还有多少剩余的blocks,如果该值显示较大,则说明查询缓存中的内存碎片过多了,可能在一定的时间进行整理。
      减少碎片:
      合适的query_cache_min_res_unit可以减少碎片,这个参数最合适的大小和应用程序查询结果的平均大小直接相关,可以通过内存实际消耗(query_cache_size - Qcache_free_memory)除以Qcache_queries_in_cache计算平均缓存大小。
      可以通过Qcache_free_blocks来观察碎片,这个值反应了剩余的空闲块,如果这个值很多,但是
      Qcache_lowmem_prunes却不断增加,则说明碎片太多了。可以使用flush query cache整理碎片,重新排序,但不会清空,清空命令是reset query cache。整理碎片期间,查询缓存无法被访问,可能导致服务器僵死一段时间,所以查询缓存不宜太大。
    • Qcache_free_memory:查询缓存的内存大小,通过这个参数可以很清晰的知道当前系统的查询内存是否够用,是多了,还是不够用,DBA可以根据实际情况做出调整。
    • Qcache_hits:表示有多少次命中缓存。我们主要可以通过该值来验证我们的查询缓存的效果。数字越大,缓存效果越理想。
    • Qcache_inserts: 表示多少次未命中然后插入,意思是新来的SQL请求在缓存中未找到,不得不执行查询处理,执行查询处理后把结果insert到查询缓存中。这样的情况次数越多,表示查询缓存应用到的比较少,效果也就不理想。当然系统刚启动后,查询缓存是空的, 这很正常。
    • Qcache_lowmem_prunes:该参数记录有多少条查询因为内存不足而被移除出查询缓存。通过这个值,用户可以适当的调整缓存大小。
    • Qcache_not_cached: 表示因为query_cache_type的设置而没有被缓存的查询数量。
    • Qcache_queries_in_cache:当前缓存中缓存的查询数量。
    • Qcache_total_blocks:当前缓存的block数量。
      PS:
      如果碎片不是问题,命中率却非常低,可能是内存不足,可以通过 Qcache_free_memory 参数来查看没有使用的内存。
      如果2者都没有问题,命中率依然很低,那么说明缓存不适合你的当前系统。可以通过设置
      query_cache_size = 0或者query_cache_type=0 来关闭查询缓存。

      show variables like'%query_cache%';

      参数讲解

    • have_query_cache 是否支持查询缓存。
  • query_cache_limit 如果某条select语句的结果集大小超过了querycachelimit的值时,这个结果集将不会被添加到查询缓存。

  • query_cache_min_res_unit 查询缓存是以块来申请内存空间的,每次申请的块大小为设定值。4K 是非常一个合理的值,不必修改。

  • query_cache_size 查询缓存的大小。

  • query_cache_type 查询缓存的类型,值有 0(OFF)、1(ON)、2(DEMOND)。OFF表示查询缓存是关闭的。ON 表示查询总是先到查询缓存中去查找,除非在select 语句中包含sql_no_cache选项。 DEMOND 表示不适用缓存,除非在select 语句中包含sql_cache选项。

  • query_cache_wlock_invalidate 该参数用于设置行级排它锁与查询缓存之间的关系,默认为为0(OFF),表示施加行级排它所的同时,该表的所有查询缓存依然有效。如果设置为1(ON),表示事假行级排它锁的同时,该表的所有查询缓存失效。

    建议

    个人建议当你有在使用redis、memcached等缓存软件时,可以将query cache其关闭,当你没有使用缓存软件,有多余的内存使用,且数据库瓶颈明显存在时,可以尝试开启查询缓存,这是个非常依赖数据表结构及SQL语句优化的功能,若数据表结构和SQL语句都针对查询缓存进行过优化,它的效果还是很不错的。

知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议

发表一下你的评论呗

回复评论代表你同意网站的 隐私政策

... 友情提示 请保留版权标识
复制成功!
目录