製品アップデート
製品お知らせ
Query Cache
機能説明
クエリキャッシュ（Query Cache）は、MySQLがデータベースのクエリ性能を向上させるために設計された機能です。データベースでクエリ文を実行するとき、この機能はクエリテキストとその対応する結果セットをクエリキャッシュに保存します。その後、同じクエリリクエストを受信した場合、データベースはまずクエリキャッシュを確認します。対応する結果がある場合、直接的に返します。再度解析、最適化、およびクエリを実行する必要がなく、これによりクエリの応答時間を大幅に短縮します。MySQLのネイティブクエリキャッシュ機能には性能関連の問題が存在するため、TDSQL-C for MySQLはMySQLのネイティブクエリキャッシュの不足点に対して再設計を行い、TDSQL-C for MySQLのクエリキャッシュ機能を導入しました。これにより、データベースのクエリ性能を効果的に向上させることができます。
MySQLのネイティブクエリキャッシュ機能の問題
クエリキャッシュのヒット率とHashクエリ性能は限定的です。
クエリキャッシュはキャッシュスペースを浪費します。
クエリキャッシュのパラメータ設定は困難です。
TDSQL-C for MySQL による上記の問題に対する最適化と説明
最適化ケース | 説明 | 価値 |
クエリキャッシュパーティション最適化 | Query Cache/Meta Hashに対してパーティション処理を行い、異なるタイプまたは範囲のクエリを特定のパーティションに正確にマッピングし、ハッシュ衝突の確率を低下させ、クエリキャッシュの位置特定と検索プロセスを加速します。 | クエリキャッシュのハッシュ性能とヒット率を向上させ、高同時実行クエリ環境においてCPUリソース消費を著しく削減し、大量のクエリリクエストにより効率的に応答します。 |
読み取り専用ノードのテーブルオープン最適化 | 読み取り専用ノードにおけるクエリキャッシュの有効性検証プロセスでのテーブルオープン操作に対して深度最適化を実施し、テーブル操作に起因する不要なキャッシュ無効化を減少させ、クエリキャッシュがより多くのシナリオで有効状態を維持することを確保します。 | キャッシュの実利用率とシステム全体のクエリ性能を向上させます。 |
ヒット率に基づくインテリジェントキャッシュ制御 | クエリキャッシュのヒット率が低いレベルにある場合、インテリジェントキャッシュ制御メカニズムを自動的に起動し、同時クエリ数を制限し、サンプリング頻度を適切に設定します。これにより、大多数のクエリがクエリキャッシュをバイパスし、専用スレッドのみがサンプリングとヒット率推定を担当します。ヒット率が回復した後、クエリキャッシュ機能を再開します。 | 低ヒット率状況下での大量クエリがキャッシュシステムに殺到することによるリソース浪費とパフォーマンス低下の問題を回避し、無効なクエリキャッシュが占有するスペースリソースを削減し、システムが異なるヒット率シナリオにおいて安定した効率的な運用を維持します。 |
キャッシュスワップオーバーヘッド最適化 | キャッシュ置換アルゴリズムとメモリ管理戦略を最適化し、キャッシュの入れ替え操作の頻度とリソース消費を削減します。科学的で合理的な戦略に基づいてキャッシュ置換を行い、高頻度かつ重要なクエリキャッシュ結果を優先的に保持します。 | 頻繁なスワップイン・アウトによるシステムパフォーマンスの変動を減少させ、クエリキャッシュが限られたメモリリソースの下で最大限の効果を発揮し、持続的かつ安定したクエリ高速化サポートを提供します。 |
LRUキャッシュ戦略の最適化 | クエリのサイズとヒット数に基づいてQuery Cache LRUキャッシュ戦略を精緻に調整し、高頻度およびスカラークエリ結果を優先的に保存し、効率の低いクエリをキャッシュすることによるスペースの浪費を回避します。 | キャッシュスペースの利用効率と特定負荷下でのシステムのクエリ応答性能を向上させ、キャッシュリソースが最も価値の高いクエリタスクに割り当てられることを確保します。 |
ダイナミックキャッシュスイッチ制御 | システムが書き込み負荷の圧力に直面した場合、クエリキャッシュをタイムリーに動的に無効化し、読み書き負荷が停止した後、秒単位で再有効化します。 | 頻繁なデータ更新によるクエリキャッシュの無効化やパフォーマンスの低下を防止し、クエリキャッシュの適応性と柔軟性を高め、システムが複雑な読み書き負荷環境でも良好なパフォーマンスを維持できるようにします。 |
ダイナミックキャッシュ容量調整 | クエリキャッシュサイズの動的リサイズをサポートし、調整プロセス中に進行中の読み書きリクエストをブロックしません。リアルタイムの負荷需要とリソース状況に基づいてキャッシュサイズを柔軟に調整します。 | 固定キャッシュサイズの設定が不適切さによる性能ボトルネック問題を解決し、キャッシュ容量調整による急激なパフォーマンス低下や中断現象の発生を回避します。これにより、システムが持続的かつ安定的に高効率なクエリ高速化サービスを提供できるようになります。 |
サポートバージョン
カーネルバージョン TXSQL 8.0 3.1.17.001以上。
適用シーン
クエリキャッシュ（Query Cache）は読み取り専用キャッシュシステムとして、局所的なホットスポット読み取りや長時間の読み取り専用の業務負荷シナリオに適用されます。
説明：
業務負荷シナリオにホットスポット読み込み負荷が存在しない場合、またはデータベース内の各テーブルが頻繁に更新されている場合、クエリキャッシュ機能を使用すると一定のパフォーマンス低下が生じる可能性があります。
機能の利用上の提案
ホットスポット読み込み負荷が存在する場合、状態指標 Qcache_free_memory（キャッシュ空き容量）と Qcache_hit_rate（直近クエリヒット率）を通じて、query_cache_size の調整が必要かどうかを判断し、読み取りパフォーマンスを向上させることができます。
キャッシュの空き容量が少なく、直近のクエリヒット率が比較的に低い場合、query_cache_size を適切に増やすことでキャッシュシステムのヒット率を向上させ、読み取りパフォーマンスを向上させることができます。
query_cache_sizeを増やしてもキャッシュヒット率が明らかに向上しない場合、現在の負荷のアクセス範囲が広く、明確なホットスポットが存在しないことを示しています。また、状態指標 Qcache_queries_in_cache（キャッシュされたクエリ数）を確認することで、現在のシステムにキャッシュされているクエリ数を観察し、業務上のホットスポット読み込みをカバーできるかどうかを判断することもできます。
query_cache_size をインスタンスメモリの10%以上に設定することは推奨されません。これは、大きな query_cache_size が OOM リスクをもたらす可能性があるためです。
利用制限
注意：
現在のバージョンでは、クエリキャッシュ（Query Cache）とデータベース監査は互換性がありません。クエリキャッシュ機能が有効になっている場合、データベース監査を有効にすることはできず、データベース監査を有効にするにはまずクエリキャッシュ機能を無効にする必要があります。逆に、データベース監査が有効になっている場合、クエリキャッシュ機能を有効にすることはできず、クエリキャッシュ機能を有効にするにはまずデータベース監査を無効にする必要があります。
使用説明
パラメータ名 | 再起動の要否 | グローバル設定か否か | 既定値 | 値の範囲 | 構成可能なノード | 説明 |
query_cache_limit | no | いいえ | 1048576 | 0 - ulong_max* | 読み書きインスタンス 読み取り専用インスタンス | この値を超えるQuery結果セットはキャッシュされません。単位：Bytes。 |
query_cache_size | no | いいえ | 1048576 | 1048576 - ulong_max* | 読み書きインスタンス 読み取り専用インスタンス | システムでクエリキャッシュに利用可能なメモリサイズ（実際に使用時にのみメモリ領域を占有）、単位：Bytes、値は1024の倍数でなければなりません。 説明： Sysbench Pocシナリオでは、テーブルサイズの20%以上をquery_cache_sizeとして設定することを推奨します。通常シナリオではBuffer Poolの5%程度を推奨します。読み取り専用テーブルが存在しない、またはホットスポットが顕著でない業務の場合は、query_cache_sizeの縮小を推奨します。 |
query_cache_type | 詳細は説明列参照 | いいえ | OFF | OFF/ON/DEMAND | 読み書きインスタンス 読み取り専用インスタンス | 設定値 OFF：機能が無効であることを示します。 設定値 ON：SELECT文でsql_no_cacheを使用してクエリキャッシュを無効にしない限り、すべての結果をキャッシュすることを示します。 設定値 DEMAND：SELECT文でsql_cacheによってキャッシュが必要と指定されたクエリのみをキャッシュすることを示します。 注意： クエリキャッシュが初期状態で無効（設定ファイルで query_cache_type=0）の場合、動的に有効化することはできず、my.cnf を設定して再起動する必要があります。ただし、クエリキャッシュの無効化は常に動的に実行することが可能です。 |
query_cache_wlock_invalidate | no | いいえ | OFF | ON/OFF | 読み書きインスタンス 読み取り専用インスタンス | テーブルに書き込みロックがかかった場合、関連するクエリキャッシュを先に無効化するかどうかを判断します。 ON：有効 OFF：無効 |
*ulong_max = 18446744073709551615
以下はクエリキャッシュに追加されたステータスです。コマンドでQuery Cache関連のステータスを確認できます。構文は以下の通りです。
SHOW STATUS LIKE 'Qcache%';
Status | 説明 |
Qcache_hits | クエリキャッシュのヒット回数。 |
Qcache_hit_rate | 直近のクエリヒット率。値は、直近の10000回のクエリキャッシュ（Qcache_search_timesが10000回増加するごと）におけるクエリキャッシュのヒット割合を示します。 |
Qcache_search_times | Queryキャッシュに対するクエリの回数（スロットリングされたクエリおよびQuery Cacheの条件を満たさないクエリはカウントされません）。 |
Qcache_total_times | QueryがQuery Cacheを経由した総回数（スロットリングなどの状況も記録されます）。 |
Qcache_free_memory | クエリキャッシュの空き容量。 |
Qcache_inserts | 結果セットが正常にキャッシュされた回数。 |
Qcache_not_cached | 結果セットのキャッシュに失敗した回数。 |
Qcache_queries_in_cache | Query Cacheにキャッシュされたクエリの数。 |
Qcache_lowmem_prunes | LRUによって追い出されたクエリキャッシュの数。 |
性能テスト
テスト環境
予備ノードの数：1台の読み書きインスタンスと1台の読み取り専用インスタンス。
クラスタ構成：8コア・16GB。
テストツール：Sysbench 1.0.20。
データベースカーネルバージョン：TXSQL 8.0 3.1.15.004。
データ量：
フルキャッシュシナリオ：Sysbenchのデータ量は約1.4GBで、合計25000×250テーブルです。
ビッグIOシナリオ：Sysbenchのデータ量は約54GBで、合計800000×300テーブルです。
テスト目標・シナリオ・手順・結果
テスト対象 | テストシナリオ | テスト手順および結果 |
クエリキャッシュによる読み取りシナリオの性能向上。 | 異なるデータ量におけるクエリキャッシュによる性能向上。 | |
クエリキャッシュサイズ（query_cache_size）が性能に与える影響。 | 異なるquery_cache_size及びデータ量におけるクエリキャッシュによる性能向上。 |
テストシナリオ1：クエリキャッシュによる読み取りシナリオの性能向上
テスト手順
1. クエリキャッシュ機能を有効にし（パラメータ query_cache_type を ON に設定）、パラメータ query_cache_size の値を1073741824（つまり1024MB）に設定します。
2. フルキャッシュシナリオにおいて、異なる同時実行数においてクラスタのQPSを記録します。Sysbenchのデータ量は約1.4GBで、合計25000×250テーブルです。
3. ビッグIOシナリオにおいて、異なる同時実行数においてクラスタのQPSを記録します。Sysbenchのデータ量は約54GBで、合計800000×300テーブルです。
テスト結果
1. フルキャッシュシナリオにおいて、マシンメモリは16GB、データ量は1.4GBです。Query Cacheを有効にした場合、ポイントクエリでは171%程度の性能向上が見られ、範囲クエリでは36%程度の性能向上が見られました。
2. ビッグIOシナリオにおいて、マシンメモリは16GB、データ量は54GBです。Query Cacheを有効にした場合、ポイントクエリでは36%程度の性能向上が見られ、範囲クエリでは10%程度の性能向上が見られました。
テストシナリオ2：クエリキャッシュサイズが性能に与える影響
テスト手順
1. 同時実行数を1024に設定し、クエリキャッシュを有効にします（パラメータ query_cache_type を ON に設定）。
2. フルキャッシュシナリオにおいて、異なるクエリキャッシュサイズ（query_cache_size）を調整し、性能テストを実施してクラスタのQPSを記録します。
3. ビッグIOシナリオにおいて、異なるクエリキャッシュサイズ（query_cache_size）を調整し、性能テストを実施してクラスタのQPSを記録します。
テスト結果
1. フルキャッシュシナリオにおいて、クエリキャッシュサイズが増加するにつれて、性能が徐々に上昇します。クエリキャッシュが2048MBの場合、ポイントクエリ Point Select に対する性能向上は約194%、範囲クエリ Range Select に対する性能向上は74%です。
2. ビッグIOシナリオにおいて、クエリキャッシュサイズが増加するにつれて、性能が徐々に上昇します。クエリキャッシュが2048MBの場合、ポイントクエリ Point Select に対する性能向上は約72%、範囲クエリ Range Select に対する性能向上は19%です。
フィードバック