MySQL取消了Query Cache的原因

MySQL之前有一个查询缓存Query Cache,从8.0开始,不再使用这个查询缓存,那么放弃它的原因是什么呢?在这一篇里将为您介绍。

MySQL查询缓存是查询结果缓存。它将以SEL开头的查询与哈希表进行比较,如果匹配,则返回上一次查询的结果。进行匹配时,查询必须逐字节匹配,例如 SELECT * FROM t1; 不等于select * from t1;,此外,一些不确定的查询结果无法被缓存,任何对表的修改都会导致这些表的所有缓存无效。因此,适用于查询缓存的最理想的方案是只读,特别是需要检查数百万行后仅返回数行的复杂查询。如果你的查询符合这样一个特点,开启查询缓存会提升你的查询性能。

随着技术的进步,经过时间的考验,MySQL的工程团队发现启用缓存的好处并不多。

首先,查询缓存的效果取决于缓存的命中率,只有命中缓存的查询效果才能有改善,因此无法预测其性能。

其次,查询缓存的另一个大问题是它受到单个互斥锁的保护。在具有多个内核的服务器上,大量查询会导致大量的互斥锁争用。

通过基准测试发现,大多数工作负载最好禁用查询缓存(5.6的默认设置):query_cache_type = 0

如果你认为会从查询缓存中获得好处,请按照实际情况进行测试。

  • 数据写的越多,好处越少
  • 缓冲池中容纳的数据越多,好处越少
  • 查询越复杂,扫描范围越大,则越受益

MySQL8.0取消查询缓存的另外一个原因是,研究表明,缓存越靠近客户端,获得的好处越大。关于这份研究请参考https://proxysql.com/blog/scaling-with-proxysql-query-cache/

下图源自上面的网址:

除此之外,MySQL8.0新增加了对性能干预的工具,例如,现在可以利用查询重写插件,在不更改应用程序的同时,插入优化器提示语句。另外,还有像ProxySQL这样的第三方工具,它们可以充当中间缓存。

综合以上原因,MySQL8.0不再提供对查询缓存的支持,如果用户从5.7版本升级至8.0,考虑使用查询重写或其他缓存。

全文完。

以上就是MySQL取消了Query Cache的原因的详细内容,更多关于MySQL Query Cache的资料请关注我们其它相关文章!

(0)

相关推荐

  • MySQL的Query Cache原理分析

    原理 QueryCache(下面简称QC)是根据SQL语句来cache的.一个SQL查询如果以select开头,那么MySQL服务器将尝试对其使用QC.每个Cache都是以SQL文本作为key来存的.在应用QC之前,SQL文本不会被作任何处理.也就是说,两个SQL语句,只要相差哪怕是一个字符(例如大小写不一样:多一个空格等),那么这两个SQL将使用不同的一个CACHE. 不过SQL文本有可能会被客户端做一些处理.例如在官方的命令行客户端里,在发送SQL给服务器之前,会做如下处理: 过滤所有注释 

  • MySQL高速缓存启动方法及参数详解(query_cache_size)

    MySQL query cache从4.1版本开始提供了,不过值今天本人才对其进行研究.默认配置下,MySQL的该功能是没有启动的,可能你通过show variables like '%query_cache%';会发现其变量have_query_cache的值是yes,MYSQL初学者很容易以为这个参数为YES就代表开启了查询缓存,实际上是不对的,该参数表示当前版本的MYSQL是否支持Query Cache,实际上是否开启查询缓存是看另外一个参数的值:query_cache_size ,该值为

  • 对于mysql的query_cache认识的误区

    其实,这一种说法是不完全正确的.首先第一点,mysql的query_cache的键值并不是简单的query,而是query加databasename加flag.这个从源码中就可以看出.在这里不做重点描述,后续可以针对于这一点再具体分析.重要的是第二点,是不是加了空格,mysql就认为是不同的查询呢?实际上这个是要分情况而言的,要看这个空格加在哪. 如果空格是加在query之前,比如是在query的起始处加了空格,这样是丝毫不影响query cache的结果的,mysql认为这是一条query,

  • MySQL取消了Query Cache的原因

    MySQL之前有一个查询缓存Query Cache,从8.0开始,不再使用这个查询缓存,那么放弃它的原因是什么呢?在这一篇里将为您介绍. MySQL查询缓存是查询结果缓存.它将以SEL开头的查询与哈希表进行比较,如果匹配,则返回上一次查询的结果.进行匹配时,查询必须逐字节匹配,例如 SELECT * FROM t1; 不等于select * from t1;,此外,一些不确定的查询结果无法被缓存,任何对表的修改都会导致这些表的所有缓存无效.因此,适用于查询缓存的最理想的方案是只读,特别是需要检查

  • MySQL的Query Cache图文详解

    目录 一.原理概述 二.Query Cache系统变量 1. have_query_cache 2. query_cache_limit 3. query_cache_min_res_unit 4. query_cache_size 5. query_cache_type 6. query_cache_wlock_invalidate 三.Query Cache状态变量 1. Qcache_free_blocks 2. Qcache_free_memory 3. Qcache_hits 4. Q

  • MySQL kill不掉线程的原因

    背景 在日常的使用过程中,时不时会遇到个别,或者大量的连接堆积在 MySQL 中的现象,这时一般会考虑使用 kill 命令强制杀死这些长时间堆积起来的连接,尽快释放连接数和数据库服务器的 CPU 资源. 问题描述 在实际操作 kill 命令的时候,有时候会发现连接并没有第一时间被 kill 掉,仍旧在 processlist 里面能看到,但是显示的 Command 为 Killed,而不是常见的 Query 或者是 Execute 等.例如: mysql> show processlist; +

  • MySQL sql_mode修改不生效的原因及解决

    前言 近期多次聊到sql_mode的话题,也是多次遇到相关问题,今天就趁热打铁,再给大家带来一个sql_mode的案例分享. 场景模拟 基于业务敏感性的考虑,下面涉及的表.存储过程等均非真实数据,但并不影响排查过程. (1)客户侧开发童鞋创建了一个存储过程,该存储过程没有严格遵守group by标准语法 session 1: mysql> delimiter // mysql> create procedure test_for_group_by() -> begin -> sel

  • MySQL无法创建外键的原因及解决方法

    关联2张表时出现了无法创建外键的情况,从这个博客看到,问题出在第六点的Charset和Collate选项在表级和字段级上的一致性上.我的2张表的编码charset和collate不一致,2张表都执行执行SQL语句: alter table 表名 convert to character set utf8; 完美解决问题: ps:下面看下MySQL无法创建外键.查询外键的属性 MyISAM 和InnoDB 讲解 InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型,这两个表类型各

  • Lost connection to MySQL server during query的解决

    Error: Lost connection to MySQL server during query 错误信息很明显了,在查询的时候丢失了和MYSQL数据库服务器的连接. MYSQL不稳定.

  • mysql数据库中字符集乱码问题原因及解决

    前言 有的时候我们在查看数据库数据时,会看到乱码.实际上,无论何种数据库只要出现乱码问题,这大多是由于数据库字符集设定的问题. 下面我们就介绍一下,数据库的字符集的设定及乱码问题的解决. mysql数据库的字符集 直白的说,字符就像是单个的文字,编码就像是给每个文字的编号,字符集就像是字符与编码的集合,校验规则就是字符集的对应的排序规则,字符集加上对应的校验规则就是语言.(每种字符集可以有多种校对规则,但都有一个默认的校对规则) mysql数据库可以通过设定字符集,来使用对应的字符集和检验规则来

  • MySQL too many connections错误的原因及解决

    今天中午,开发测试环境的MySQL服务报了一个too many connections的错误,从问题上看,可能是连接池被打满了,导致所有的连接都不可用了. 在这种情况下,最为直接的办法就是重新设置最大连接数,查看my.cnf文件,里面关于连接数的参数有两个,分别是: max_connections:最大连接数 max_user_connections:用户最大连接数 其中,第一个参数确定的是该实例的最大连接数,第二个参数确定的是单个用户的最大连接数. 一般的线上环境,为了保险起见,一般这两个参数

  • 记一次Mysql不走日期字段索引的原因小结

    目录 背景 探索 总结 背景 在一个表中,dataTime字段设置是varchar类型,存入的数据是日期格式的数据,并且为该字段设置了索引.但是在日志记录中,有一条关于该表的慢查询.查询语句为: select * from digitaltwin_meteorological where dataTime > '2021-10-15'; explain分析sql语句,发现sql语句执行了全表扫描.为何sql中用了dataTime索引列,为啥还走全表扫描呢? 探索 一:起初,认为是dataTime

随机推荐