ApsaraDB RDS:Fast Query Cache

MySQL ネイティブのクエリキャッシュを使用しない理由

MySQL ネイティブのクエリキャッシュは、すべてのキャッシュ操作にグローバルロックを使用します。高い同時実行性環境下では、このロックがボトルネックとなります。CPU コアを追加しても、QPS が向上するどころか低下することがあります。メモリ管理の不備がこの問題をさらに悪化させます。断片化の蓄積、回収の遅延、キャッシュヒット率の低さが、大幅なパフォーマンス低下を引き起こします。これらの問題により、MySQL は MySQL 8.0 でネイティブのクエリキャッシュを完全に廃止し、それ以前のバージョンではデフォルトで無効にしました。

Fast Query Cache がこれらの問題を解決する方法

Alibaba Cloud は、クエリキャッシュをゼロから再設計しました。

パラメーター

手順

Fast Query Cache は追加のメモリを消費するため、まず innodb_buffer_pool_size を再設定してメモリの空き容量を確保します。

1. innodb_buffer_pool_size を現在の値の 90% に削減します。これにより解放された 10% をクエリキャッシュに利用できます。たとえば、現在の値が {DBInstanceClassMemory*7/10} の場合、{DBInstanceClassMemory*63/100} に設定します。詳細については、「InnoDB バッファープールサイズの変更」をご参照ください。

2. ワークロードに基づいて query_cache_size を設定します。パラメーターの変更の詳細については、「インスタンスパラメーターの変更」をご参照ください。

   • 結果セットのサイズがわかっている場合： query_cache_size を 結果セットサイズの 20% に設定します。

   • 結果セットのサイズがわからない場合： query_cache_size を [innodb_buffer_pool_size の 10%] に設定します。

   重要

   ApsaraDB RDS for MySQL インスタンスの仕様を変更しても、query_cache_size は自動的にスケーリングされません。仕様変更が有効になった直後に、このパラメーターを再設定してください。

3. query_cache_type を [1] に設定して、Fast Query Cache を有効にします。詳細については、「インスタンスパラメーターの変更」をご参照ください。

セッションレベルでのテスト

グローバル設定を変更する前に、他のユーザーに影響を与えることなく、単一の接続で Fast Query Cache をテストできます。

-- このセッションでのみ Fast Query Cache を有効にする
SET SESSION query_cache_type = 1;

-- このセッションでのみ Fast Query Cache を無効にする
SET SESSION query_cache_type = 0;

全ヒットの読み取りワークロード (100% キャッシュヒット率、512 MB キャッシュ)

プライマリキーに対する POINT SELECT ステートメントを使用した oltp_point_select スクリプトを使用します。

表 1. キャッシュヒット率 100% での読み取りクエリの QPS

同時実行数が増加するにつれて、MySQL ネイティブのクエリキャッシュの QPS は急激に低下し、64 スレッドで最大 43% 減少します。一方、Fast Query Cache の QPS は上昇を続け、1,024 スレッドで QC-OFF を最大で 127.30% 上回ります。

高ヒット率の読み取りワークロード (80% 以上のキャッシュヒット率、512 MB キャッシュ)

複数のレコードを返す範囲クエリを使用した oltp_read_only スクリプトを使用します。

表 2. キャッシュヒット率 80% 以上での読み取りクエリの QPS

Fast Query Cache の QPS は同時実行数の増加とともに上昇を続け、QC-OFF を 124% 以上上回るピークに達します。一方、MySQL ネイティブのクエリキャッシュは、高い同時実行性で QC-OFF を 22% 下回るまで低下します。

低ヒット率の読み取りワークロード (約 10% のキャッシュヒット率、16 MB キャッシュ)

oltp_read_only スクリプトを使用します。16 MB のキャッシュはデータセットよりもはるかに小さいため、頻繁なエビクションが発生し、ヒット率は約 10% になります。

表 3. キャッシュヒット率約 10% での読み取りクエリの QPS

MySQL ネイティブのクエリキャッシュでは、低ヒット率の条件下で QPS が最大 48% 低下します。一方、Fast Query Cache の QPS は QC-OFF の 1～4% 以内に留まり、キャッシュミスがほとんどの場合でも、実質的にオーバーヘッドは発生しません。

読み取りと書き込みが混在するワークロード

頻繁なテーブル更新によってキャッシュエントリが常に無効化される oltp_read_write スクリプトを使用します。

表 4. 読み取りおよび書き込みクエリの QPS

Fast Query Cache を使用した場合、読み取りと書き込みが混在するワークロードにおいて QPS の低下は最大でも 2.17% にとどまります。増分無効化メカニズムにより、頻繁な書き込みが発生してもキャッシュメンテナンスのオーバーヘッドは低く抑えられています。

Fast Query Cache の使用を推奨する場合

• ワークロードが読み取り集中型で、書き込み頻度が低い場合 (例： eコマースサイトの商品詳細ページ、レポート用クエリ)

• 読み取り/書き込み比率が高い特定のテーブルをキャッシュしたい場合。TABLE_STATISTICS テーブルを確認してこれらのテーブルを特定し、query_cache_type = 2 と組み合わせて SQL_CACHE キーワードを使用することで、対象のクエリのみをキャッシュします。TABLE_STATISTICS のクエリの詳細については、「Performance Insight」をご参照ください。

Fast Query Cache をグローバルに有効にする前に、InnoDB バッファープールのヒット率を確認してください。

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';

ヒット率 = 1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)

InnoDB バッファープールのヒット率が 80% 未満の場合、バッファープールにはすでにメモリプレッシャーがかかっています。この状態で Fast Query Cache を有効にすると (innodb_buffer_pool_size を削減する必要があるため)、パフォーマンスが低下する可能性があります。キャッシュを有効にする前に、インスタンスメモリを増やすか、クエリを最適化してください。

Fast Query Cache を避けるべき場合

• 書き込み負荷の高いワークロード： 頻繁な書き込みにより、キャッシュが常に無効化され、キャッシュの利点がほとんど得られないままオーバーヘッドが発生します。高頻度のトランザクションシステムでは、query_cache_type = 0 のままにしてください。

• リアルタイムデータの要件： キャッシュされた結果は、実データより古い可能性があります。金融市場データのように古いデータの読み取りが許容されないユースケースでは、キャッシュを無効にするか、クエリごとに SQL_NO_CACHE を使用してください。

適切な query_cache_type 値の選択

query_cache_type はセッションレベルの変更をサポートしているため、グローバル設定を変更せずに、接続ごとにキャッシュ動作を調整できます。

SET SESSION query_cache_type = 1;  -- このセッションで有効化
SET SESSION query_cache_type = 0;  -- このセッションで無効化