几个参数
query_cache_type：为ON时开启，为OFF关闭，为DEMAND时则只有查询语句中有sql cache时才使用缓存
query_cache_size: 缓存的内存空间
query_cache_min_res_unit: 分配内存块的最小单位
query_cache_limit：缓存可使用的内存最大值
缓存使用及注意
在使用上缓存后，对于select语句：首先去缓存里查询是否有对应的缓存，具体是根据sql语句和作用的表生成一个key，去内存取值；如果这个key没有缓存，则执行sql语句，再把结果存到缓存中。
对于增删改语句：执行完增删改语句后，要记录好这些语句影响的表，再去缓存空间中找到从这些表拿到的缓存结果，将这些缓存结果置为失效。
注意：
1. 若select中有不确定函数，则用不上缓存。如current_data，因为这个函数的值时刻变化，缓存没有意义
2. 内存分配要合理，太小影响缓存结果，太大会导致 os 僵死
3. 内存分配最小单位要设置合理，调小点有利于减少内存碎片，但太小影响分配效率
4. 缓存也是有很多开销的，如查找，更新，置为失效缓存，以及使用内存时的互斥信号量。要衡量开销与收益
5. 缓存绝对不适合写多读少的场景，这会频频把缓存置为失效
InnoDB的缓存实现特点
前面的总结中也提到了InnoDB的MVCC机制，是一种变种的行级锁，这里就不详细介绍了。由于MVCC机制，事务不能使用创建事务ID在自己后面的行的缓存。举个例子：首先是有事务1、2、3、4对某个行进行查询，但由于某些原因他们执行被阻塞，这时事务5也来查询这个行并且成功了，然后把结果缓存起来。但是事务1，2，3，4再继续执行时是不能直接从缓存中拿这个行的，因为这个行的事务标记是晚于他们的事务5，事务1，2，3，4必须老实去执行 sql 语句。
实际上和MVCC机制下的数据读取类似：为了防止不可重复读，只读创建事务ID晚于自己的行。
建议
1. 缓存也是有开销的，如果是写多读少的场景，不要用缓存。只有读多，且读操作比较耗时才考虑缓存。
2. 可以考虑使用专门的表存储某些结果，例如某些统计数字。
3. 尽量用客户端缓存，这样缓存就与关系数据库无关；缓存数据库和关系数据库分离，不用读写行时维护缓存，操作起来更快。