昙花一现的Query Cache

[Pu Jiexuan]

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

mysql8.0直接移除了query cache

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来的简单直接呢？