MySQL セレクトキャッシュメカニズムの使用に関する詳細な説明

MySQL クエリ キャッシュはデフォルトでオンになっています。ある程度、クエリの効果は向上しますが、最善の解決策ではない可能性があります。変更やクエリが多い場合、変更によってキャッシュ障害が発生し、サーバーに大きなオーバーヘッドが発生します。query_cache_type [0 (OFF) 1 (ON) 2 (DEMAND)] を通じてキャッシュスイッチを制御できます。

MySQL クエリ キャッシュは、メモリ内で HASH 構造でマップされるため、大文字と小文字が区別されることに注意してください。HASH アルゴリズムの基礎は SQL ステートメントを構成する文字であるため、SQL ステートメントに変更があれば再キャッシュされます。これは、プロジェクト開発で SQL ステートメントの記述標準を確立する必要がある理由でもあります。

1. キャッシュするタイミング

a) mysql クエリ キャッシュの内容は、select の結果セットです。キャッシュは完全な SQL 文字列をキーとして使用し、大文字と小文字、スペースなどが区別されます。つまり、キャッシュ ヒットを得るには、2 つの SQL ステートメントが完全に一致している必要があります。

b) パラメータがまったく同じであっても、準備されたステートメントは結果をキャッシュしません。 5.1以降は改善されるとのこと。

c) where 条件に current_date、now などの特定の関数が含まれている場合、それらはキャッシュされません。

d) 日付などの関数が時間または日数でデータを返す場合は、最初に計算してから渡すのが最適です。
select * from foo where date1=current_date -- キャッシュされません
select * from foo where date1='2008-12-30' -- キャッシュされた正しいアプローチ

e) 大きすぎる結果セットはキャッシュされません (< query_cache_limit)

2. 無効化する場合

a) テーブルデータのいずれかの行が変更されると、テーブルに関連するすべてのキャッシュが直ちに無効になります。

b) もっと賢く、変更されたコンテンツがキャッシュ コンテンツであるかどうかを判断してみませんか?キャッシュの内容の分析は非常に複雑なため、サーバーは最大限のパフォーマンスを追求する必要があります。

3. パフォーマンス

a) キャッシュは必ずしもあらゆる状況でパフォーマンスを向上させるとは限らない

クエリや変更の数が多い場合、キャッシュ メカニズムによってパフォーマンスが低下する可能性があります。変更するたびにシステムでキャッシュ無効化操作が実行され、かなりのオーバーヘッドが発生するためです。

さらに、システム キャッシュへのアクセスは単一のグローバル ロックによって制御され、ロックが解除されるまで大量のクエリがブロックされます。したがって、キャッシュを設定すると必ずパフォーマンスが向上すると単純に想定しないでください。

b) 大きな結果セットはキャッシュされません。

大きすぎる結果セットはキャッシュされませんが、MySQL は結果セットの長さを事前に把握していないため、リセット設定後にキャッシュが臨界値 query_cache_limit に追加されるまで待機し、その後キャッシュを破棄するだけです。これは効率的な操作ではありません。 mysql ステータスの Qcache_not_cached が大きすぎる場合は、結果セットが大きくなる可能性のある SQL に SQL_NO_CACHE 制御を明示的に追加できます。
query_cache_min_res_unit = (query_cache_size – Qcache_free_memory) / Qcache_queries_in_cache

4. メモリプールの使用

MySQL クエリ キャッシュは、メモリ プール テクノロジを使用して、オペレーティング システムではなく、メモリの解放と割り当てをキャッシュ自体で管理します。メモリ プールが使用する基本単位は可変長ブロックであり、結果セット キャッシュはリンク リストを通じてこれらのブロックを連結します。結果セットを保存するときに、結果セットが最終的にどれくらいの大きさになるかわからないためです。ブロックの最小長は query_cache_min_res_unit であり、結果セットの最後のブロックはトリム操作を実行します。

クエリ キャッシュは、データベースのパフォーマンスを向上させる上で非常に重要な役割を果たします。

セットアップも非常に簡単で、構成ファイルに query_cache_type と query_cache _size の 2 行を記述するだけで、MySQL のクエリ キャッシュは非常に高速になります。ヒットが見つかると、それが直接クライアントに送信され、CPU 時間が大幅に節約されます。

もちろん、SELECT 以外のステートメントはキャッシュに影響を与え、キャッシュ内のデータが期限切れになる可能性があります。 UPDATE ステートメントによって部分的なテーブル変更が行われると、そのテーブルのバッファリングされたデータはすべて無効になります。これは、パフォーマンスのバランスを取るために MySQL が行わない対策です。なぜなら、各 UPDATE で変更されたデータをチェックし、バッファの一部を取り出す必要がある場合、コードの複雑さが増すからです。

query_cache_type 0 はキャッシュが使用されないことを意味します。1 はキャッシュが使用されることを意味し、2 は必要に応じて使用されることを意味します。

1 に設定すると、バッファリングは常に有効になります。バッファリングが不要な場合は、次のステートメントを使用する必要があります。

コードは次のとおりです

my_table から SQL_NO_CACHE * を選択...

2 に設定されている場合、バッファリングを有効にする必要があり、次のステートメントを使用できます。

コードは次のとおりです

my_table から SQL_CACHE * を選択し、...

バッファのステータスを表示するには、SHOW STATUS を使用します。

コードは次のとおりです

mysql> 'Qca%' のようなステータスを表示します。
+-------------------------+-----------+
| 変数名 | 値 |
+-------------------------+-----------+
| Qcache_queries_in_cache | 8 |
| Qcache_挿入 | 545875 |
| Qcache_hits | 83951 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 2343256 |
| Qcache_free_memory | 33508248 |
| Qcache_free_blocks | 1 |
| Qcache_total_blocks | 18 |
+-------------------------+-----------+
セット内の行数は 8 です (0.00 秒)

ヒット率を計算する必要がある場合は、サーバーが実行した SELECT ステートメントの数を知る必要があります。

コードは次のとおりです

mysql> 'Com_sel%' のようなステータスを表示します。
+---------------+---------+
| 変数名 | 値 |
+---------------+---------+
| Com_select | 2889628 |
+---------------+---------+
セット内の1行（0.01秒）

この場合、MySQL は 2,889,628 のクエリのうち 83,951 をヒットしましたが、そのうち INSERT ステートメントは 545,875 のみでした。したがって、この 2 つの合計は合計クエリ数 280 万からは程遠いため、この例で使用されているバッファ タイプは 2 であることがわかります。

タイプ1の例では、Qcache_hitsの値はCom_selectよりはるかに大きくなります。

以上がこの記事の全内容です。皆様の勉強のお役に立てれば幸いです。また、123WORDPRESS.COM を応援していただければ幸いです。