早上一打开网站，就看到了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有作用吧？)