MySQLクエリキャッシング：最大キャッシュサイズ128 MBに制限されていますか？
私のアプリケーションは非常にデータベース集約型であるため、アプリケーションとMySQLデータベースが可能な限り効率的に連携して動作するように一生懸命努力しました。
現在、サーバーで実行されているクエリの特性に合わせてMySQLクエリキャッシュを調整しています。
query_cache_sizeはキャッシュに保存できるデータの最大量であり、query_cache_limitはキャッシュ内の単一の結果セットの最大サイズです。
現在のMySQLクエリキャッシュは次のように構成されています。
query_cache_size=128M
query_cache_limit=1M
tuning-primer.shは、実行中のシステムに関する次のチューニングヒントを提供します。
QUERY CACHE
Query cache is enabled
Current query_cache_size = 128 M
Current query_cache_used = 127 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 99.95 %
Current query_cache_min_res_unit = 4 K
However, 21278 queries have been removed from the query cache due to lack of memory
Perhaps you should raise query_cache_size
MySQL won't cache query results that are larger than query_cache_limit in size
mysqltuner.plは、次のチューニングヒントを提供します。
[OK] Query cache efficiency: 31.3% (39K cached / 125K selects)
[!!] Query cache prunes per day: 2300654
Variables to adjust:
query_cache_size (> 128M)
両方のチューニングスクリプトは、query_cache_sizeを上げる必要があることを示唆しています。ただし、query_cache sizeを128M以上に増やすと、mysqltuner.plに従ってパフォーマンスが低下する場合があります（ http://mysqltuner.pl/ を参照）。
この問題にどのように取り組みますか？ mysqltuner.plの警告にもかかわらずquery_cache_sizeを増やしますか、それとも何らかの方法でクエリロジックを調整しますか？ほとんどのデータアクセスはHibernateによって処理されますが、アプリケーションではかなり多くの手作業でコーディングされたSQLも使用されます。
通常、「キャッシュサイズが大きすぎる」という警告は、物理メモリがほとんどなく、キャッシュ自体を交換する必要があるか、OSが必要とするリソース（ファイルキャッシュなど）を使用することを前提に発行されます。
十分なメモリがある場合は、query_cache sizeを増やすことは安全です（1GBクエリキャッシュを使用したインストールを見てきました）。
しかし、クエリキャッシュを正しく使用していると確信していますか？多くのverbatim repeatクエリがありますか？典型的なクエリの例を投稿してください。
キャッシュにスワップのリスクがない場合でも、mysqltuner.pyによって発行される警告は実際に関連しています。以下で詳細に説明されています： http://blogs.Oracle.com/dlutz/entry/mysql_query_cache_sizing
基本的に、MySQLはキャッシュが大きいほどキャッシュのグルーミングに多くの時間を費やします。また、キャッシュは中程度の書き込み負荷でも非常に揮発性であるため（クエリは頻繁にクリアされます）、大きすぎるとアプリケーションのパフォーマンスに悪影響を及ぼします。アプリケーションのquery_cache_sizeとquery_cache_limitを微調整し、挿入ごとのヒット数が最も多いブレークポイント、少数のlowmem_prunesを見つけて、データベースサーバーの負荷に注意してください。そうすることも。
キャッシュを増やすのは簡単です、それは「それほど多くないメモリ」のことではありません！
例えば マニュアル を読むと、この引用が得られます：
クエリキャッシュのサイズを過度に大きくすると、キャッシュを維持するために必要なオーバーヘッドが増加する可能性があります。おそらく、キャッシュを有効にする利点を超えてしまいます。通常、数十メガバイトのサイズが有益です。数百メガバイトのサイズはそうではないかもしれません。
ゼロ以外のプルーンレートは、クエリキャッシュのサイズを増やす必要があることを示している場合があります。ただし、キャッシュを維持するオーバーヘッドはそのサイズとともに増加する可能性があるため、これを少しずつ増やして結果を監視してください。プルーンを排除するためにキャッシュのサイズを劇的に増やす必要がある場合、ワークロードがクエリキャッシュと適切に一致しない可能性が高くなります。
そのため、できる限り多くのクエリキャッシュを配置しないでください。
最良の方法は、クエリキャッシュを徐々に増やし、サイトのパフォーマンスを測定することです。パフォーマンスに関する質問では、これはある種のデフォルトですが、このような場合、「テスト」はあなたができる最善のことの1つです。
query_cache_sizeとhighの制限の設定には注意してください。 MySQLは、単一のスレッドのみを使用してクエリキャッシュから読み取ります。
query_cache_size 4Gおよびquery_cache_limit 12Mに設定すると、クエリキャッシュ率は85％でしたが、接続のスパイクが繰り返し発生することがわかりました。
query_cache_sizeを64Kで256Mに変更した後query_cache_limitクエリキャッシュ率は50％に低下しましたが、全体的なパフォーマンスは向上しました。
クエリキャッシュのオーバーヘッドは約10％なので、クエリキャッシュを無効にします。通常、ヒット率を40または50％を超えて取得できない場合、クエリキャッシュがデータベースに適していない可能性があります。
私はこのトピックについてブログに書いています... Mysql query_cache_size performance here 。
クエリキャッシュは、挿入があるたびに無効化/フラッシュされ、InnoDB /キャッシュを使用してクエリキャッシュを回避するか、非常に小さな値に設定します。