我們就分析之前產(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，因為CACHE也是需要執(zhí)行多次查詢，只不過后面的查詢是讀取前面的CACHE罷了。
- 我們修改為如下就有CACHE了
根據(jù)上面分析，同一個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，所以下面執(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)造前面，不過不影響，因為這是數(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
