昙花一现的Query Cache
pupuk opened this issue · comments
Query Cache
本想缓存每次请求的结果,无奈最后事与愿违;
https://dev.mysql.com/doc/refman/5.7/en/query-cache-operation.html
SHOW VARIABLES LIKE '%query_cache%'
5.7.29的默认结果
have_query_cache YES
query_cache_limit 1048576
query_cache_min_res_unit 4096
query_cache_size 1048576
query_cache_type OFF
query_cache_wlock_invalidate OFF
https://www.cnblogs.com/JiangLe/p/5337383.html
查询缓存的最终结果是事与愿违:
之所以查询缓存并没有能起到提升性能的做用,客观上有如下两点原因
1、把SQL语句的hash值作为键,SQL语句的结果集作为值;这样就引起了一个问题如 select user from mysql.user 和 SELECT user FROM mysql.user
这两个将会被当成不同的SQL语句,这个时候就算结果集已经有了,但是一然用不到。
2、当查询所基于的低层表有改动时与这个表有关的查询缓存都会作废、如果对于并发度比较大的系统这个开销是可观的;对于作废结果集这个操作也是要用并发
访问控制的,就是说也会有锁。并发大的时候就会有Waiting for query cache lock 产生。
3、至于用不用还是要看业务模型的。
历史的演进,最权威的文档:
https://dev.mysql.com/doc/refman/5.7/en/query-cache.html
说是昙花一现,也走过好几年的岁月。主要是现在互联网OLTP,udpate和insert的业务变得越来越多。缓存这一块可以用redis去做,所以mysql的query cahce越来越鸡肋,以至于在mysql8中被弃用。
对于如下的场景:
The query cache can be useful in an environment where you have tables that do not change very often and for which the server receives many identical queries. This is a typical situation for many Web servers that generate many dynamic pages based on database content.
如果不想引入redis,还是有意义的,可是这种场景,我为什么不选用innodb引擎,多开几个innodb_buffer_pool_instances, 扩大一点innodb_buffer_pool_size来的简单直接呢?