一、查询缓存的误区
刚接触QC时，觉得是个好东西，可以将查询的结果放到QC中，这样极大的提升查询的速度，但是后来了解到如果对表进行做DML或者DDL，QC相对应的缓存就会释放，这样对于频繁更改的数据库是没有任何意义的。
二、查询缓存场景
每次执行select结果，会放到查询缓存中，这样下次在执行的时候，就不需要具体的执行sql，只要访问查询访问中的缓存即可。
适合的场景：
1、select
2、访问大量的数据才有必要缓存其结果
3、返回少量数据
大量的分组、聚合、计算
查询缓存才不至于变得非常大
对于普通的交易系统来说，这个查询 意义不大，都是一些简单的sql，甚至于还有副作用。
执行一次成本很高，结果集又很小，这种sql值得被缓存。
三、查询缓存的配置
1、将query_cache_type，这是静态参数，需要重启数据库。
0是关闭查询缓存
1打开查询缓存，缓存所有的sql语句的结果，除非select sql_no_cache 提示，表示这个结果不放在缓存里面。
2打开查询缓存，但是只是缓存select sql_cache 对应的结果集。 比较推荐使用
2、query_cache_size调整查询缓存的大小
四、查询缓存演示
开启查询缓存，MySQL中的select就会放到查询缓存中，无论什么操作，第一次放到QC中，再次执行的时候就会直接到QC中查询，这样Qcache_hits 就会加一，但是如果对该表做DML或者DDL，本来放到QC中的缓存就会被释放。
1、没有任何操作
| Qcache_hits | 0 |
| Qcache_not_cached | 2 |
| Qcache_queries_in_cache | 0 |
2、执行
select * from t1 where id=1;
| Qcache_hits | 0 |
| Qcache_not_cached | 2 |
| Qcache_queries_in_cache | 1 |
select * from t1 where id=1;
| Qcache_hits | 1 |
| Qcache_not_cached | 2 |
| Qcache_queries_in_cache | 1 |
insert into t1 values(4,'dfd');
| Qcache_hits | 1 |
| Qcache_not_cached | 2 |
| Qcache_queries_in_cache | 0 |
select * from t1 where id=1;
| Qcache_hits | 1 |
| Qcache_not_cached | 2 |
| Qcache_queries_in_cache | 1 |
select * from t1 where id=1;
| Qcache_hits | 2 |
| Qcache_not_cached | 2 |
| Qcache_queries_in_cache | 1 |
mysql> reset query cache;
Query OK, 0 rows affected (0.00 sec)
| Qcache_hits | 2 |
| Qcache_inserts | 2 |
| Qcache_queries_in_cache | 0 |
五、查询缓存中的参数
| Qcache_free_blocks | 1 | #指的是空闲块数，指的是系统分配给MySQL进程的缓存总大小空间中还没有使用的空间
| Qcache_free_memory | 20953960 | #空闲空间,指的是还没有被操作系统分配出去的内存空间。
| Qcache_hits | 12 | #指的是命中次数
| Qcache_inserts | 3 | #向缓存空间中插入的缓存的次数
| Qcache_lowmem_prunes | 0 | #内存太小，修剪内存的次数
| Qcache_not_cached | 0 | #指没有命中的次数
| Qcache_queries_in_cache | 0 | #缓存的个数
| Qcache_total_blocks | 1 | #总块数，指的是系统分配给MySQL进程的缓存总大小空间
flush query_cache #碎片整理
reset query_cache #清空缓存
