MySQL Query Cache に関するいくつかのやり取り

今日はMySQLオンラインでメモリ使用量アラームが発生したので、innodb_buffer_pool_sizeとクエリキャッシュの使用について、キャッシュを中心にmysqlのメモリ使用量のパラメータを確認してみました。

query_cache_type はデフォルトでオンになっており、キャッシュ領域のデフォルトのサイズ query_cache_size は通常 256M を超えないようにすることをお勧めします:

mysql> show variables like '%cache%';
+------------------------------+----------------------+
| Variable_name                | Value                |
+------------------------------+----------------------+
| binlog_cache_size            | 32768                |
| binlog_stmt_cache_size       | 32768                |
| have_query_cache             | YES                  |
| key_cache_age_threshold      | 300                  |
| key_cache_block_size         | 1024                 |
| key_cache_pision_limit     | 100                  |
| max_binlog_cache_size        | 18446744073709547520 |
| max_binlog_stmt_cache_size   | 18446744073709547520 |
| metadata_locks_cache_size    | 1024                 |
| query_cache_limit            | 1048576              |
| query_cache_min_res_unit     | 4096                 |
| query_cache_size             | 33554432             |
| query_cache_type             | ON                   |
| query_cache_wlock_invalidate | OFF                  |
| stored_program_cache         | 256                  |
| table_definition_cache       | 400                  |
| table_open_cache             | 512                  |
| thread_cache_size            | 8                    |
+------------------------------+----------------------+
18 rows in set (0.00 sec)


mysql>

。

"Qcache_free_blocks": 現在クエリ キャッシュに残っているブロックの数。値が大きい場合、
はクエリ キャッシュ内にメモリの断片が多く存在することを意味し、それを整理する適切な機会を見つける必要がある可能性があります ()。
●「Qcache_free_memory」: クエリ キャッシュの現在の残りメモリ サイズ。このパラメータを通じて、現在のシステムのクエリ キャッシュ メモリ サイズが十分であるか、増やす必要があるか、多すぎるかをより正確に観察できます。
● "Qcache_hits": ヒット数。このパラメータを通じて、クエリ キャッシュの基本的な効果を確認できます。
● "Qcache_inserts": ミスの数とその後の挿入。 2 つのパラメーター「Qcache_hits」と「Qcache_inserts」を使用して、クエリ キャッシュのヒット率を計算できます。
クエリ キャッシュのヒット率 = Qcache_hits / (Qcache_hits + Qcache_inserts)
● "Qcache_ lowmem_prunes": クエリの数メモリ不足のため、クエリ キャッシュからクリアされました。
"Qcache_lowmem_prunes" と "Qcache_free_memory" を組み合わせることで、システムのクエリ キャッシュのメモリ サイズが本当に十分であるかどうか、またメモリ不足によりクエリが頻繁に置き換えられるかどうかをより明確に理解できます。
● "Qcache_not_cached": query_cache_type の設定または query_cache_type の設定が原因でキャッシュできないクエリの数
● "Qcache_queries_in_cache": 現在のクエリ キャッシュ内のクエリの数
● "Qcache_total_blocks": 現在のクエリ キャッシュ内のブロック数。
クエリ キャッシュの制限
クエリ キャッシュは、物理データ ページではなく論理的に構造化された結果セットを保存するため、パフォーマンスが向上する一方で、
また、特定の制限もいくつかあります。
a) 5.1.17 より前のバージョンでは、変数の決定に役立つクエリをキャッシュできませんでしたが、バージョン 5.1.17 以降、クエリ キャッシュは変数の決定に役立つクエリをサポートし始めました
b) すべてのサブクエリ外部クエリ SQL はサポートされません。
c) プロシージャ、関数、トリガー内のクエリはキャッシュできません。
d) 実行するたびに異なる結果が得られる可能性のある他の多くの関数を含むクエリはキャッシュできません。
上記の制限を考慮して、クエリ キャッシュを使用する場合は、適切なテーブルのデータのみがクエリ キャッシュに入力され、特定のクエリ キャッシュのクエリ結果のみが入力されるように、厳密な設定を通じて使用することをお勧めします。

さらに、
Qcache_free_blocks 値が少し高い場合は、フラッシュ クエリ キャッシュを使用してクリーンアップできます。

友人の提案:

最初の提案: 読み取り操作が多い場合は、比率を見てください。簡単に言えば、それがユーザーリストテーブルであるかどうか、つまりデータ比率は次のとおりです。製品リストについて話すなど、比較的固定されているものは、これらのライブラリが比較的集中化されており、データベース内のプラクティスが比較的小さい場合には、開くことができます。

2 つ目:

「不正行為」を行う場合、たとえば入札中にストレス テストを行う場合、クエリ キャッシュをオンにすることで引き続き QPS サージ効果を受けることができます。フロントエンド接続プールはすべて同じ構成です。ほとんどの場合、書き込みは多いがアクセスが少ない場合は、そのサイトを開かないでください。たとえば、ソーシャル ネットワーキング サイトでは、10% の人がコンテンツを生成し、残りの 90% がコンテンツを開きます。非常に効果的ですが、QQ メッセージやチャットの場合は非常に致命的です。

3 番目:

Web サイトが小さいか、高い同時実行性がないかどうかは関係ありません。高い同時実行性では、多くの qcache ロックが待機していることがわかります。クエリ キャッシュを開くことはお勧めできません

上記は MySQL に関するものです。クエリ キャッシュに関する経験の交換については、PHP 中国語 Web サイト (www.php.cn) に注目してください。