MySQL查询缓存是MySQL在8.0版本之前提供的一个特性，它跟Oracle缓存SQL语句的执行计划是不同的。这里是简单粗暴地将 SELECT 语句的文本与发送到客户端的相应结果一起存储。如果后面收到相同的查询语句，则服务器从查询缓存中检索结果，而不是再次解析并执行该语句
查询缓存这种做法，遇到相同的查询语句时，不需要再对SQL解析和执行，也不用访问磁盘，直接从内存获取查询结果，大幅度减少磁盘I/O操作，提高查询效率。
但是再仔细想一想，这里面是不是也有点不对劲的地方？
查询语句和查询结果以键值对的形式被直接缓存在内存中。因为是对SQL语句做hash计算，所以查找缓存的时候，SQL语句必须是字节级的匹配，完全一致的SQL才能命中缓存，也意味着在缓存中SELECT * FROM test和select * from test是不一样的。
这里可以看出来，查询缓存对内存资源的利用不合理。实际开发过程中，如果我们书写SQL的格式不能保证统一，那么同样的查询就会被缓存多次。
一旦涉及到缓存，我们就要考虑缓存失效的问题，如果数据表存在数据（表数据，表结构以及索引）的变更，那么这张表的查询缓存就要被清除。这时候频繁的变更必定导致更大的系统开销。此时查询缓存也就要考虑使用的实际场景有哪些了。
最重要的还有一个大招，就是MySQL查询缓存有严重的可伸缩性问题，并且很容易成为严重的瓶颈。它不能与多核计算机上在高吞吐量工作负载情况下进行扩展。关于这个具体说明，可以参考一下MySQL官方人员的博客文章：dev.mysql.com/blog-archiv…
最最最后，还有一个有趣的点，有测试表明缓存越靠近客户端，性能提升的越多，可以看看这篇关于 ProxySQL Query Cache 的文章：proxysql.com/blog/scalin…
虽然MySQL8.0以后把查询缓存去掉了，但是查询缓存设计的思想，我可以借鉴一下，在适当的时候，添加Redis缓存等，针对数据库做一些优化。
