我們就分析之前產(chǎn)生的CACHE的地方
位置1：includes解決N+1查詢問題
新建案例分析
添加路由
get 'query_cache_six'
添加動作
def query_cache_six
end
product.product_second_tag.ID的訪問方式不是執(zhí)行product.product_second_tag查詢之后再訪問ID字段product.product_second_tag是查詢后得到結(jié)果集，同一個each里面多次出現(xiàn)訪問ID、SecondTagLength掀鹅、SecondTagName直接訪問的結(jié)果集合所以不再執(zhí)行sql查詢任岸，所以這種方式訪問只執(zhí)行一次sql查詢-----自然不會出現(xiàn)CACHE，因?yàn)镃ACHE也是需要執(zhí)行多次查詢疚顷，只不過后面的查詢是讀取前面的CACHE罷了。
- 我們修改為如下就有CACHE了
根據(jù)上面分析，同一個each里面只有1條sql薯酝。
each遍歷3次，因?yàn)榈谝淮蝒ach的sql和第二次的sql都是SELECT `product_second_tags`.* FROM `product_second_tags` WHERE `product_second_tags`.`ID` = 'st1' LIMIT 1爽柒，是相同的sql吴菠，所以第二次是CACHE，所以下面執(zhí)行的3條sql中第2條是CACHE浩村。
多次each的情況下做葵，第一次是sql查詢，后面每次都是CACHE心墅，CACHE可以不止一次
如下二級標(biāo)簽為st1的CACHE出現(xiàn)3次酿矢。
位置2：I多條件拼接查詢、模型與表任意命名
這個我們在控制器動作中使用includes包含進(jìn)來的關(guān)聯(lián)表數(shù)據(jù)都是一次性查詢怎燥，肯定沒有CACHE（CACHE需要多次查詢的情況下才出現(xiàn)）瘫筐。而tags表沒有用includes，所以each多次就存在相同sql就執(zhí)行CACHE铐姚，（該筆記CACHE應(yīng)該有兩次CACHE才對策肝，3次each為st1的結(jié)果中后兩次是CACHE，我們截圖是在新數(shù)據(jù)構(gòu)造前面谦屑，不過不影響驳糯，因?yàn)檫@是數(shù)據(jù)構(gòu)造導(dǎo)致的，邏輯和其他筆記內(nèi)容都對）氢橙。
位置3：(9)II多條件拼接查詢
也是一樣的分析酝枢，不在描述
提交到git倉庫
git add .
git commit -m "查詢CACHE第二部分"
git push -u https://github.com/xiaohuacc/active_record.git master
