MySQLのクエリキャッシュについて
クエリキャッシュは、クエリの解決プロセスを開いた後：
クエリキャッシュがオンになっている場合、クエリを解析する前に、その後のMySQLは、クエリ、クエリデータキャッシュヒットするかどうかをチェックするために優先させて頂きます。現在のクエリは、クエリキャッシュにヒットしてしまった場合、MySQLはクエリの結果を返す前にユーザー権限をチェックします。許可は問題ではない場合、MySQLは、他のすべてのフェーズ（構文解析、最適化、実行、など）をスキップするキャッシュから直接結果を得るために、クライアントに返さ。この場合、クエリは実行計画なしに解決されることはありません、実行されません。
オープンクエリキャッシュのMySQLサーバーは、MySQLサーバがクエリによって算出された各SELECT文で受信したハッシュ値は、ハッシュアルゴリズムを指定します場合は、その値はクエリキャッシュに一致する橋。
- 一致しない場合、このハッシュ値は、ハッシュリストに格納され、クエリ結果セットは、各ノードがキャッシュ内のアドレスに対応するハッシュ値リスト橋Quey格納された結果セットが格納され、キャッシュに格納され、問い合わせこれは、テーブル情報の一部に関する。
- クエリによって同じハッシュ値に一致する場合は、直接クライアントに返さキャッシュクエリの結果セットに対応します。
現在、MySQLのクエリキャッシュの文がクエリキャッシュを適用する前に、ストアへの鍵として、各SQLテキストに基づいているMySQLのクエリキャッシュのキャッシュではありません使用し、SELECT文、他の同様のショーをキャッシュします、SQL文は、いずれかを行うことはありません処理。でも、1つの文字の違い限り、つまり、2つのSQL文では、2つのSQLキャッシュが別のアドレスを使用します（たとえば、ケースは同じ、1つのより多くのスペース、そしてより多くのコメントではありません）。そのようなものとして次の3つのSQLそれらの結果は同じであるが、三つの異なるキャッシュに格納されます。*名前SELECT = 'surfchen'人々から; SELECT * FROM人/ ねえ〜 /名= 'surfchen';人SELECT * FROM名= 'surfchen';
MySQLのキャッシュ機構
MySQLのキャッシュは単にあなたが同じSQLを実行した場合、サーバはSQLを解析し、実行するために行く必要なしに、キャッシュから直接結果を得るために、クエリ結果のSQL文をキャッシュする意味と。表が変更された場合には、もはや有効ではないだろうすべてのキャッシュされたクエリのテーブルを使用して、キャッシュ内の関連するエントリの値が空になっている照会します。変更は、本明細書において、INSERT、UPDATE、DELETE、TRUNCATEを含む任意のデータ構造又はテーブルの変更を意味するALTER TABLE、DROP TABLE DROPデータベース、またはMERGEを使用して照会テーブルマッピングテーブルにそれらの変更を含む、など。明らかに、これは頻繁にテーブルのために更新され、クエリキャッシュは適していませんが、いくつかのまれにしか変化するデータテーブルのために、同じSQLクエリがたくさんある、クエリキャッシュは素晴らしいパフォーマンスを保存します。
それは同じように考えることができるクエリはまったく同じ（同じバイトのためのバイト）でなければなりません。また、他の理由のために、同じクエリ文字列は異なるものと考えることができます。異なるデータベース、異なるプロトコルバージョンを使用して、または別のデフォルトの文字セットが異なるクエリとクエリがキャッシュされていると考えられています。
キャッシュルール
キャッシュを開設し、MySQLサーバがメモリに自動的にクエリを返す結果セットになり、その後、メモリから直接取得次の時間を確認してください。
結果キャッシュは、クライアントキャッシュのクエリ結果ので、あなたが別のクライアントを使用することができ、セッションによって共有されています。
MySQLのクエリ結果のキャッシュの内容を選択セットには、キーとして完全なSQL文字列を使用し、大文字と小文字が区別され、スペースなどのキャッシュ。つまり、2つのSQLは、キャッシュヒットにつながるとまったく同じでなければなりません。すなわち、それは正確に、クエリキャッシュは、別のクエリであると考えられて少し異なるが文字ケース限り、から来るかコメントクライアントからの問い合わせの使用であり、任意の治療を行うことはありませんクエリキャッシュ、SQLへのMySQLサーバをチェックすることです。
プリペアドステートメントでもまったく同じパラメータあれば、結果をキャッシュすることはありません。5.1の後に改善されます。
どこ条件関数は、今というように、そのようCURRENT_DATEなど、一切不確実になることはありませんキャッシュが含まれていないよう。
復帰は数時間または数日のレベルに基づいている場合機能、日付、それは再伝送の内部をうまくするのが最善です。
結果セットのキャッシュの多くではありません（<query_cache_limit）
サブサブテーブルの環境でMySQLデータベースキャッシュは仕事をしません
SQL、カスタム関数の実装をトリガーがあり、MySQLは、キャッシュは動作しません。
手動でキャッシュをクリア
以下の3つのSQLを使用することができます手動でキャッシュをクリアします：
- FLUSH QUERY CACHE;＃クエリキャッシュメモリの断片化をクリーンアップ
- RESET QUERY CACHE;＃は、クエリキャッシュからすべてのクエリーを削除します
- FLUSH TABLES;＃近く開いているすべてのテーブル、およびクエリキャッシュがクリアされます。この操作
キャッシュメモリ管理メカニズム
むしろ、オペレーティングシステムからよりも、メモリの割り当てと解放を管理するために、技術を使用してMySQLのクエリキャッシュメモリプール。メモリ・プールの基本単位は、可変長ブロックによって使用される情報の種類、サイズ、データ等を格納するために使用され、一緒にキャッシュ・ブロック列によって結果セットこれらのリストを。最小のブロック長は、query_cache_min_res_unitのです。
サーバが起動されると、それは必要とされているメモリキャッシュが完了空きブロックで初期化されます。ときにキャッシュクエリの結果への必要性、アプリケーションのデータ・ブロック・スペース・パラメータquery_cache_min_res_unitの設定で空きブロックから始まるが、小さくても、キャッシュされたデータならば、彼はスペースを割り当てるようになったとき、クエリがないこの時点で、結果を返すため、アプリケーション・データ・ブロックは、これですどのくらいの結果を予測します。
あなたは、操作が遅くなるので、ブロックをロックする必要がメモリ空間のブロックを割り当て、MySQLは過剰の完全な解放を格納する際に予備がある場合は、引き続き適用されない場合は、この操作を避けるため、できるだけ小さなメモリブロックを選択しようとします。
しかし、同時動作ならば、残りのスペースをリサイクルする必要性は非常に小さい、小さいquery_cache_min_res_unitのより、再び使用することはできません、フラグメントを生成します。
有効になりません
大きなキャッシュのキャッシュミスが、実際には、クエリの大半は、サーバーにキャッシュされている場合は、次のことが発生している必要があります。
- クエリキャッシュはまだ完了してウォームアップ、MySQLがクエリ結果がキャッシュされるにはチャンスを持っていない、ではありません。
- 前にクエリが実行されていません。アプリケーションがクエリを実行繰り返されない場合は、ウォームアップが完了した場合でも、まだキャッシュミスがたくさんあるでしょう。
- キャッシュ無効化操作あまり、キャッシュの断片化、メモリの不足、データの変更は、キャッシュミスが発生します。*修正データ（などCom_update、Com_delete、を含む）パラメータCOM_の事情を経由して閲覧することができ、あなたはまた、メモリ不足に起因する回数Qcache_lowmem_prunes障害によって見ることができます。
テーブルにデータを書き込むとき、表は、この操作は、グローバルロック操作であるので、キャッシュ容量が大きい場合、消費はしばらくの間、システムが死んだことがあり、素晴らしいものだ、失敗するように設定されているキャッシュのすべてでなければなりません保護します。
InnoDBテーブル、あなたがテーブルを変更すると、キャッシュの無効化を設定しますが、これらの特性の複数のバージョンを一時的に限り、トランザクションがコミットされるまで、トランザクションのコミット前に、すべてのクエリがキャッシュを使用することはできません、その他の事項シールドを変更しますトランザクションの時間が、大幅にクエリキャッシュのヒットを削減します。
MySQLのクエリキャッシュの破片の最適化
MySQLのクエリキャッシュの利点と欠点
長所：
SQLのアクセス許可を確認するために、クエリの後で解析し、クエリの前にクエリキャッシュクエリは、クライアントからの照会要求を受けたMySQLの中で行われました。その後、MySQLクライアントクエリのSQLを受けた後、ただ唯一の適切な権限検証する必要があり、結果クエリキャッシュを見つけることになります、あなたもオプティマイザモジュールの後に計画の実施を最適化するために分析する必要があり、より多くはありません任意の相互作用のストレージエンジンが発生する必要はありません。クエリキャッシュは、メモリベースであるため、非常に高い効率が得られ、このようにディスクI / OとCPUの計算量を低減する、メモリ対応する結果から直接返されます。
短所：
ハッシュハッシュ計算が消費をもたらすにリソースを検索クエリ。query_cache_typeセット1（すなわちON）にあれば、MySQLは、それぞれ、SELECTタイプのクエリのハッシュ計算を受信し、その後、このクエリが存在するのキャッシュ結果を探します。ハッシュ計算と検索効率が十分に高いですが、頭上から生じるクエリーを無視することができますが、それは高い同時実行に来るとき、クエリの数千人、ハッシュ計算があるとルックアップオーバーヘッドもたらしましたそれは真剣に受け止めなければなりません。
クエリキャッシュの失敗の問題。あなたはより頻繁にテーブルを変更する場合は、クエリキャッシュの失敗率が非常に高いになります。さらに、テーブル構造、またはインデックスの変化を含む、変更テーブルデータテーブルの変更を意味するだけでなく。
別のクエリが、クエリと同じクエリ結果がキャッシュされ、これはメモリリソースの過剰消費になります。（そのハッシュ値が異なるため）クエリ文字場合、異なる空間やコメント、クエリキャッシュは、別のクエリとみなされます。
関連システム変数は、メモリの断片化の多くの原因となります不合理設定されており、これはクエリキャッシュメモリまで頻繁にきれいにつながります。
クエリキャッシュの方法を使用するように設定します
3通りの方法でオープンクエリキャッシュを開き、query_cache_type変数を使用します。
ON：通常のキャッシュ。SQL_NO_CACHEまたは他の非決定的関数、通常はキャッシュされたクエリ結果を指定されていない場合は、SELECT文を使用して、クエリの中で述べています。
DEMAND：キャッシュのみを指定しSQL_CACHE。クエリを使用してSELECT文で述べて、あなただけのSELECT文の下にクエリ結果キャッシュSELECT文でSQL_CACHEを指定する必要があります。
select SQL_CACHE name from user where id = 15; #只有明确指定 SQL_CACHE 的SELECT语句，才会将查询结果缓存。
OFF：クエリキャッシュ。
効果的なのは、すぐに、サービス障害を再起動します
mysql> set global query_cache_type=1;
my.cnfを、query_cache_type = OFFは、開始MySQLサービスの後、mysqlのコマンドラインでクエリキャッシュを開くために、上記のステートメントを使用すると、エラーが発生します。
ERROR 1651 (HY000): Query cache is disabled; restart the server with query_cache_type=1 to enable it
このような場合に、クエリキャッシュは、MySQLコマンドラインで開かれていない、あなたは、my.cnfのquery_cache_type = ONを変更して、MySQLのサービスを再起動する必要があります。
恒久
my.cnfのを変更します。
query_cache_type = ON
MySQLサービスを再起動し
クエリキャッシュのサイズを設定します。
query_cache_size ：查询缓存的总体可用空间。
query_cache_size = 0であれば、あなたはquery_cache_type = ONを設定した場合でも、クエリキャッシュがまだ仕事にできないこと。
効果的なのは、すぐに、サービス障害を再起動します
mysql> set global query_cache_size=536870912; #单位为字节，必须为1024的倍数。
永久的な
変更のmy.cnf：
query_cache_size = 500M #支持单位：K,M,G
クエリキャッシュ関連のパラメータ
キャッシュ機能に関連付けられたサーバー変数：
mysql> SHOW GLOBAL VARIABLES LIKE '%query_cache%';
+------------------------------+----------+
| Variable_name | Value |
+------------------------------+----------+
| have_query_cache | YES |
| query_cache_limit | 1048576 |
| query_cache_min_res_unit | 4096 |
| query_cache_size | 16777216 |
| query_cache_strip_comments | OFF |
| query_cache_type | ON |
| query_cache_wlock_invalidate | OFF |
+------------------------------+----------+
変数説明：
have_query_cache：MySQLサーバはクエリキャッシュをサポートしているかどうか。
query_cache_limit：MySQLは最大の結果をキャッシュすることができ、その結果がこの値よりも大きい場合、クエリのサイズは、それがキャッシュされません。
query_cache_min_res_unitの：キャッシュ割り当ての（バイトで）クエリ最小ブロックサイズ。デフォルト値は4096（4キロバイト）です。結果は時々しないように、そう、保存されている間、クエリ、MySQLがクエリキャッシュでクエリ結果を保存する場合は、しかし、あなたは、検索結果の横に比較的大きな、よりquery_cache_min_res_unitの値よりも、この時間のmysqlの結果を保存する場合すべての結果は、ワンタイムは、保存されたすべての後に得られたが、query_cache_min_res_unitの使用後に、結果セットを保存するためのメモリ空間の各割り当てを、そのようなブロックの再分配に続いて、十分ではない、その後、再配布ブロックであれば、によって言うことです、このようなプッシュは、それは、クエリで複数のメモリ割り当てを動作させるためのmysql可能です。クエリの結果はいくつかの小さな結果であるならば、規制query_cache_min_res_unitのは、あなたのメモリを最適化することができ、デフォルトのquery_cache_min_res_unitのは、メモリの断片化、大量のを引き起こす可能性があり、適切な検索結果が大きくresuleのいくつかであるならば、あなたは適切なトーンquery_cache_min_res_unitのを置くことができます
（query_cache_size-Qcache_free_memory）/ Qcache_queries_in_cache：平均単一クエリキャッシュのサイズを計算します
query_cache_size：バイト単位のクエリ全体の利用可能なバッファ空間、それは1024の倍数でなければなりません。
query_cache_strip_comments：クエリキャッシュ内のSQLクエリ文をキーとして格納されているかどうかを制御するためのコメントセクションを除去した後。
query_cache_type：タイプクエリキャッシュ、キャッシュ機能がオンされ、三つの方法になっ{ON | OFF | DEMAND}。
query_cache_wlock_invalidate：テーブルは、デフォルトではオフ、キャッシュ内のデータを返すかどうかを、ロックされている場合は、それもお勧めします。クエリキャッシュ内のクエリの結果は、他のクライアントがロックされていない場合、通常、MyISAMテーブル上のクライアントWRITEロックは、あなたがテーブルを照会することができるとき。この変数が1に設定されている、あなたは、クエリキャッシュ内のテーブルへのすべてのクエリが無効化されるように、テーブルの上にロックを書き込むことができます。だから、ロックが有効になっているとき、強制することができることを他のクライアントが終了を待つために、テーブルにアクセスしようとします。
キャッシュに関連付けられた状態変数
mysql> SHOW GLOBAL STATUS LIKE 'Qcache%';
+-------------------------+----------+
| Variable_name | Value |
+-------------------------+----------+
| Qcache_free_blocks | 1 | #查询缓存中的空闲块
| Qcache_free_memory | 16759656| #查询缓存中尚未使用的空闲内存空间
| Qcache_hits | 16 | #缓存命中次数
| Qcache_inserts | 71 | #向查询缓存中添加缓存记录的条数
| Qcache_lowmem_prunes | 0 | #表示因缓存满了而不得不清理部分缓存以存储新的缓存，这样操作的次数。若此数值过大，则表示缓存空间太小了。
| Qcache_not_cached | 57 | #没能被缓存的次数
| Qcache_queries_in_cache | 0 | #此时仍留在查询缓存的缓存个数
| Qcache_total_blocks | 1 | #共分配出去的块数
+-------------------------+----------+
キャッシュヒット率を計算します
mysql> SHOW GLOBAL STATUS WHERE Variable_name='Qcache_hits' OR Variable_name='Com_select';
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| Com_select | 279292490 | #非缓存查询次数
| Qcache_hits | 307366973 | # 缓存命中次数
+---------------+-----------
キャッシュのヒット率：Qcache_hits /（Qcache_hits + Com_select）
「ヒットと書き込み」比
mysql> SHOW GLOBAL STATUS WHERE Variable_name='Qcache_hits' OR Variable_name='Qcache_inserts';
+----------------+-----------+
| Variable_name | Value |
+----------------+-----------+
| Qcache_hits | 307416113 | #缓存命中次数
| Qcache_inserts | 108873957 | #向查询缓存中添加缓存记录的条数
+----------------+-----------+
この比が3より大きい場合Qcache_hits / Qcache_inserts＃：1、バッファが有効であることを示し、それは10を超えた場合：で「ヒットと書かれている」の割合は1、非常に満足です。
