(12)查询CACHE第二部分

我们就分析之前产生的CACHE的地方

位置1：includes解决N+1查询问题

新建案例分析

添加路由

get 'query_cache_six'

添加动作

def query_cache_six
end

product.product_second_tag.ID的访问方式不是执行product.product_second_tag查询之后再访问ID字段product.product_second_tag是查询后得到结果集，同一个each里面多次出现访问ID、SecondTagLength、SecondTagName直接访问的结果集合所以不再执行sql查询，所以这种方式访问只执行一次sql查询-----自然不会出现CACHE，因为CACHE也是需要执行多次查询，只不过后面的查询是读取前面的CACHE罢了。

• 我们修改为如下就有CACHE了
  根据上面分析，同一个each里面只有1条sql。
  each遍历3次，因为第一次each的sql和第二次的sql都是SELECT `product_second_tags`.* FROM `product_second_tags` WHERE `product_second_tags`.`ID` = 'st1' LIMIT 1，是相同的sql，所以第二次是CACHE，所以下面执行的3条sql中第2条是CACHE。

多次each的情况下，第一次是sql查询，后面每次都是CACHE，CACHE可以不止一次

如下二级标签为st1的CACHE出现3次。

位置2：I多条件拼接查询、模型与表任意命名

这个我们在控制器动作中使用includes包含进来的关联表数据都是一次性查询，肯定没有CACHE（CACHE需要多次查询的情况下才出现）。而tags表没有用includes，所以each多次就存在相同sql就执行CACHE，（该笔记CACHE应该有两次CACHE才对，3次each为st1的结果中后两次是CACHE，我们截图是在新数据构造前面，不过不影响，因为这是数据构造导致的，逻辑和其他笔记内容都对）。

位置3：(9)II多条件拼接查询

也是一样的分析，不在描述

提交到git仓库

git add .
git commit -m "查询CACHE第二部分"
git push -u https://github.com/xiaohuacc/active_record.git master