早上一打開網站，就看到了Percona官網發布的最新的關於 mysql query cache的文章：
https://www.percona.com/blog/2015/08/07/mysql-query-cache-worst-enemy-best-friend/
還有一篇對其評論的文章：
https://blog.gslin.org/archives/2015/08/07/5906/percona-%E5%B0%8D-mysql_query_cache-%E7%9A%84%E6%B8%AC%E8%A9%A6-%E4%BB%A5-magento-%E7%82%BA%E4%BE%8B/
主要內容就是：
1. mysql的query cache有一個缺點：
The query cache is well known for its contentions: a global mutex has to be acquired for any read or write operation, which means that any access is serialized. This was not an issue 15 years ago, but with today’s multi-core servers, such serialization is the best way to kill performance.
對query cache 的讀和寫都必須要獲得一個全局鎖，也就是必須都得串行。所以當select並發很多時，必然造成鎖的競爭。降低性能。
但是原文又稱：
However from a performance point of view, any query cache hit is served in a few tens of microseconds while the fastest access with InnoDB (primary lookup) still requires several hundreds of microseconds. Yes, the query cache is at least an order of magnitude faster than any query that goes to InnoDB.
緩存命中的話，只要幾十毫秒，如果沒有命中，而走主鍵索引的話，需要幾百毫秒。但是他這裡沒有考慮，如果我們將主鍵索引放入緩存呢？
就算這樣，原文實際測試的結果卻恰恰說明了，關閉query cache，mysql有更好的並發和throutput.
第二個鏈接後面有人評論：
這個我有做過類似的試驗, 結果也很類似, 主要原因是 query cache 還是有 cost, 硬體規格不高時的確有點用處, 但是當 query 數量超過某個級數後, 就像文中數據顯示的結果一樣, 性能就會下降, buffer 開大也沒用, 反而要停用 query cache 才能保證輸出效能.(很簡單，就是全局鎖的競爭導致的)
如果要開 query cache, 只要開 1MB 就夠了, 開再多也不會有太大的提升
只要是 software cache 都有這個問題, 為了解決這個問題, server 級的 CPU 的 L3 cache 都很大, 可以有效提升效能及輸出.
關於 PK search, 跟 mysql 的 key buffer 有關. mysql 的 key buffer 的確要開大, 因為這是放 index 用的, 要開到足夠放進所有的 index, 開太小放不進所有 index, 就不能保證效能了.(但是 key_buffer_size貌似只對myisam有作用吧？)
