これに関する詳細な MySQLサーバーチームからのブログ があり、Matt Lordはこう述べています。
クエリキャッシュは、MySQL 5.6（2013）以降、デフォルトで無効になっています。これは、マルチコアマシンで高スループットのワークロードに対応できないことが知られているためです。
すべてのワークロードに改善をもたらすことができる最適化と比較して、クエリキャッシュにどのような改善を加えることができるかを検討しました。
これらの選択自体は直交していますが、エンジニアリングリソースは有限です。つまり、すべてのワークロードにより一般的に適用できる改善に投資するための戦略をシフトしているということです。
いい厄介払い ！！！
ほとんどのデータベース開発者にとって、アプリケーションで最も一般的な結果セットのサイズを正しく見積もることは困難です。大きなクエリキャッシュを持つことは、そのための大きな包帯でした。
クエリキャッシュの終了を予告した大きな理由があります。 4年前、私は投稿に回答しました なぜquery_cache_typeはデフォルトで無効にされており、MySQL 5.6から開始されますか？ 。短いですが、クエリキャッシュは常にInnoDBバッファープールの変更を検査していました。これは High Performance MySQL（第2版）のページ209-215 にあります。
私は長年にわたってこれについて述べました：
Sep 05, 2012： 頻繁なクエリキャッシュの無効化のオーバーヘッドは価値がありますか？Sep 25, 2013： クエリキャッシュエントリ（キー）を無効化していますSep 26, 2013： クエリキャッシュヒット値がデータベースで変更されないDec 23, 2013： CPUとメモリの使用率が高いMySQL
RIPクエリキャッシュ!!!
（私は他の回答に同意しますが、ここに私の2セントの価値があります。）
実装されると、...
QC できませんはGaleraまたはGroup Replicationで動作します。どちらもHAアリーナでより多くの注目を集めています。
いつ
query_cache_size大きくなり、効率が低下しました。これは、「プルーニング」の非効率性が原因です。 （注：Auroraはそれを再実装し、この問題を修正したようです。）every
SELECTにはオーバーヘッドがあります。QCが機能するかどうかがわからないためです。数十年前、これは11％と推定されていました。 QCを取り除くまで、唯一の回避策はbothquery_cache_size = 0andquery_cache_type = 0構成ファイル内。 （両方が必要だと気づいた人はほとんどいません。）一般的な本番サーバーでは、挿入が頻繁に発生します。 each insertにより、そのテーブルのallエントリがプルーニングされたため、QCはそのようなテーブルでは事実上役に立たなかった。
おそらく、私がパフォーマンスの問題について検討した何百ものシステムの95％は、QCなしで処理するほうがよいでしょう。