前面我们碰到过只是写一个查询语句，控制台输出信息中包含CACHE的情况。这个是rails内置的query cache，与页面缓存没关系，所以我们就算关闭了页面缓存，有的查询语句还是会有CACHE。下面根据简单例子和之前案例讲解CACHE。
rails的query cache的原理就是：在同一个请求周期内，如果没有update/delete/insert的操作，会对相同的sql查询进行缓存。
简单例子
- 添加路由
get 'query_cache_one'
get 'query_cache_two'
get 'query_cache_three'
get 'query_cache_four'
get 'query_cache_five'
- 添加动作
def query_cache_one
end
def query_cache_two
end
def query_cache_three
end
def query_cache_four
end
def query_cache_five
end
(1)第一种普通的情况，没有CACHE，有一条sql查询
(2)第二种普通的情况，没有CACHE，有两条sql查询
(3)第三种情况，产生CACHE
分析
第一种情况：
只有products=Product.limit(3)这条执行查询。后面products.each则是直接操作查询的结果集，针对的是结果集进行操作，所以不再继续执行查询。
第二种情况：
products=Product.limit(3)执行一条sql查询
Product.all.each也执行一条查询。
上一种情况products是结果集---我们直接对结果集each，不再执行查询。
而Product.all本身就是查询--我们执行该查询后each。
这就是本例中执行两条sql查询的原因。
第三种情况：
products=Product.limit(3)执行一条查询。而Product.limit(3).each不是直接对结果集products进行操作，而是执行Product.limit(3)的查询之后each，所以会有两条SQL语句。唯一与第二种情况不同的是第二条查询前面带有CACHE[0.0ms]。
这是因为rails的query cache就是：在同一个请求周期内，如果没有update/delete/insert的操作，会对相同的sql查询进行缓存。
第二种情况中，products=Product.limit(3)和Product.all翻译出来的sql是不一样的,一个带有LIMIT
SELECT `products`.* FROM `products` LIMIT 3
SELECT `products`.* FROM `products`
第三种情况中，products=Product.limit(3)和Product.limit(3).each翻译出来的sql都是
SELECT `products`.* FROM `products` LIMIT 3
Rails会对相同的sql查询进行缓存，所以本身代码跟第二种情况一样都是执行两条查询。但是这两条查询都是一样的，所以rails会进行sql缓存，第一条执行查询为Product Load，第二条查询使用query cache所以前面就有CACHE了。
不同方式实现相同sql的CACHE注意事项
同一个请求中相同SQL会使用query cache；判断SQL相同是根据控制台的翻译sql信息必须严格保持一致，比如下面两个动作，第一个动作我们是把Product.limit(3)在控制台的翻译sql复制到find_by_sql里面，sql语句一模一样所以识别为相同sql使用CACHE。
而虽然纯sql查询关键字大小写、空格这些都无所谓，但是rails的query cache笔记弱----必须要翻译后的sql大小写、空格这些都一样才识别为相同sql进而使用CACHE。
下面我们第一条sql是SELECT，而我们写的find_by_sql里面是select，大小写不同所以识别为不同的SQL（就是少一个空格也识别为不同的sql查询）。
提交到git仓库
我们直接在master分支提交
git add .
git commit -m "查询CACHE第一部分(顺便修改index.html.erb)"
