查询缓存中表数据_超详细的mysql数据库查询缓存总结，值得收藏

概述

查询缓存(Query Cache，简称QC)，存储SELECT语句及其产生的数据结果。闲来无事，做一下这块的总结，也做个备忘！

---

工作原理

查询缓存工作原理如下：

缓存SELECT操作的结果集和SQL语句，key为sql，value为查询结果集；

如果新的SELECT语句到了，以这个sql为key去缓存中查询，如果匹配，就把缓存的结果集返回；

匹配标准：与缓存的SQL语句是否完全一样，sql中字母区分大小写以及中间的空格，简单理解为存储了一个key-value结构，key为sql，value为sql查询结果，匹配时使用Java的String的equals()，例如：

select age from user 与 select AGE from user不会匹配，因为大小写不同；select age from use 与 select age from user不会匹配，因为空格不同；

sql两边的空格可忽略，可以认为是对key进行过trim操作之后再进行equals比较。

---

查看mysql设置参数

执行

show variables like '%query_cache%';

可以看到相关参数：

query_cache_type：0-不启用查询缓存；1-启用，2-启用，默认值为0； query_cache_size：设置缓存区总大小，允许设置query_cache_size的值最小为40K，默认1M，推荐设置为：64M/128M；query_cache_limit：限制缓存区最大能缓存的单条查询记录集大小，默认设置为1M

query_cache_type为1时，只要符合查询缓存的要求，客户端的查询语句和记录集都可以缓存起来，如果SQL中加上 SQL_NO_CACHE将不缓存；

query_cache_type为2时，只要SQL中添加了参数：SQL_CACHE，且符合查询缓存的要求，客户端的查询语句和记录集，则可以缓存起来。

---

查看缓存使用情况

show status like '%Qcache%%';

可以看到相关参数：

Qcache_hits：缓存命中次数；Qcache_inserts：缓存中插入次数，每缓存一次加1，注意这个不是缓存数量；

---

开启查询缓存

设置选项query_cache_type = 1 ，同时设置query_cache_size = 67108864；

注：query_cache_size的值设置在100MB以内即可。在MySQL里查询缓存是由一个全局锁在控制，每次更新查询缓存的内存块都需要进行锁定。

---

关闭查询缓存

设置选项query_cache_type = 0，同时设置query_cache_size = 0。

---

适用场景

用于频繁提交同一个语句，并且该表数据变化不是很频繁的场景，例如一些静态页面，或者页面中的某块不经常发生变化的信息。

由于查询缓存需要缓存最新数据结果，因此表数据发生任何变化(insert、update、delete或其他可能产生数据变化的操作)，都会导致查询缓存被刷新。因而，对于一个更新频率非常低而只读查询频率非常高的场景下，打开查询缓存还是比较有优势的。

---

不适用场景

查询缓存严格要求2次SQL请求要完全一样，包括SQL语句，连接的数据库、协议版本、字符集等因素都会影响。下面为查询缓存不适用的几个场景：

1. 子查询；
2. 过程、函数、触发器、event中调用的SQL，或者引用到这些结果的；
3. 查询中涉及一些特殊函数时，例如：BENCHMARK()、CURDATE()、CURRENT_TIME()、CURRENT_TIMESTAMP()、NOW()、SLEEP()、CONNECTION_ID()、CURRENT_DATE()、CURRENT_USER()、PASSWORD()、RAND()、UUID()、ENCRYPT()、LAST_INSERT_ID()等等；
4. 查询涉及到mysql，information_schema或performance_schema。
5. 类似SELECT…LOCK IN SHARE MODE、SELECT…FOR UPDATE、SELECT..INTO OUTFILE/DUMPFILE、SELECT * FROM ... WHERE autoincrement_col IS NULL的查询；
6. SELECT执行计划用到临时表；
7. 未引用任何表的查询，例如SELECT 1+2；
8. 查询产生了告警(warnings)；
9. SELECT语句中存在SQL_NO_CACHE关键字；
10. 涉及到分区表。

可见，使用查询的缓存的限制非常多。当使用场景中以只读为主，很少有更新的情况时，再考虑开启查询缓存。

---

后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注一下~