結果セットのキャッシュを使用したパフォーマンスのチューニング

  • [アーティクル]

結果セットのキャッシュが有効になっている場合、専用 SQL プールでは、繰り返し使用できるよう、クエリ結果がユーザー データベースに自動的にキャッシュされます。 これにより、以降のクエリ実行で永続キャッシュから直接結果を取得できるため、再計算は必要ありません。 結果セットのキャッシュにより、クエリのパフォーマンスが向上し、コンピューティング リソースの使用量が減少します。 さらに、キャッシュされた結果セットを使用するクエリはコンカレンシー スロットをまったく使用しないため、既存のコンカレンシー制限にはカウントされません。 セキュリティのため、キャッシュされた結果にアクセスできるのは、そのユーザーがキャッシュされた結果を作成したユーザーと同じデータ アクセス許可を持っている場合のみです。 結果セットのキャッシュは、データベースとセッション レベルでは既定で OFF になっています。

注意

結果セットのキャッシュは、DECRYPTBYKEY と組み合わせて使用しないでください。 この暗号関数を使う必要がある場合は、実行時に結果セットのキャッシュを (セッションレベル、データベースレベルのいずれかで) 無効にするようにしてください。

主なコマンド

ユーザー データベースに対する結果セットのキャッシュをオン/オフにする

セッションに対する結果セットのキャッシュをオン/オフにする

キャッシュされた結果セットのサイズを確認する

キャッシュをクリーンアップする

キャッシュされないもの

結果セットのキャッシュがデータベースに対してオンになると、キャッシュがいっぱいになるまで、すべてのクエリに対して結果がキャッシュされます。ただし、次のクエリは除きます。

  • ベース テーブルのデータやクエリに変化がなくても非決定論的な関数やランタイム式が組み込まれているクエリ。 たとえば、DateTime.Now() や GetDate() などです。
  • ユーザー定義関数を使用したクエリ
  • 行レベルのセキュリティを持つテーブルを使用したクエリ
  • 64 KB を超える行サイズのデータを返すクエリ
  • 10 GB を超えるサイズの大きなデータを返すクエリ

Note

  • 一部の非決定論的関数とランタイム式は、同じデータに対する繰り返しクエリに対して決定論的である場合があります。 たとえば、ROW_NUMBER() などです。
  • クエリの結果セットの行の順序がアプリケーション ロジックにとって重要である場合は、クエリで ORDER BY を使用します。
  • ORDER BY 列のデータが一意でない場合、結果セットのキャッシュが有効か無効かに関係なく、ORDER BY 列内の同じ値を持つ行の行順は保証されません。

重要

結果セットのキャッシュを作成し、キャッシュからデータを取得する操作は、専用 SQL プール インスタンスの制御ノードで行われます。 結果セットのキャッシュを有効にした場合、大きな結果セット (たとえば 1 GB 超) を返すクエリを実行すると、制御ノードでスロットリングが大きくなり、インスタンスでのクエリ応答全体が遅くなる可能性があります。 これらのクエリは、通常、データの探索または ETL 操作で使用されます。 制御ノードに負荷を与え、パフォーマンスの問題が発生するのを防ぐため、ユーザーは、このようなクエリを実行する前に、データベースの結果セットのキャッシュを無効にする必要があります。

クエリの結果セットのキャッシュ操作にかかる時間に、次のクエリを実行します。

SELECT step_index, operation_type, location_type, status, total_elapsed_time, command
FROM sys.dm_pdw_request_steps
WHERE request_id  = <'request_id'>;

結果セットのキャッシュを無効にして実行されたクエリの出力例を次に示します。

場所の種類やコマンドなどのクエリ結果が示されたスクリーンショット。

結果セットのキャッシュを有効にして実行されたクエリの出力例を次に示します。

.dbo が呼び出された select * from [D W ResultCache D b] コマンドがあるクエリ結果を示すスクリーンショット。

キャッシュされた結果が使用される場合

次のすべての要件が満たされている場合は、キャッシュされた結果セットがクエリで再利用されます。

  • クエリを実行しているユーザーに、クエリで参照されているすべてのテーブルへのアクセス権がある。
  • 新しいクエリと、結果セットのキャッシュを生成した前のクエリが完全に一致している。
  • キャッシュされた結果セットが生成されたテーブル内でデータおよびスキーマの変更がない。

次のコマンドを実行して、クエリが結果キャッシュ ヒットで実行されたのか、結果キャッシュ ミスで実行されたのかを確認します。 result_cache_hit 列では、キャッシュ ヒットの場合は 1、キャッシュ ミスの場合は 0、結果セットのキャッシュが使用されなかった理由については負の値が返されます。 詳細については、sys.dm_pdw_exec_requests を確認してください。

SELECT request_id, command, result_cache_hit FROM sys.dm_pdw_exec_requests
WHERE request_id = <'Your_Query_Request_ID'>

キャッシュされた結果の管理

結果セットのキャッシュの最大サイズは、データベースあたり 1 TB です。 基になるクエリ データが変更されると、キャッシュされた結果は自動的に無効になります。

キャッシュの削除は、このスケジュールに従って専用 SQL プールによって自動的に管理されます。

  • 結果セットが使用されていない場合、または無効になっている場合は、48 時間ごと。
  • 結果セットのキャッシュが最大サイズに近づいた場合。

ユーザーは、次のいずれかのオプションを使用して、結果セットのキャッシュ全体を手動で空にすることができます。

  • データベースの結果セットのキャッシュ機能をオフにする
  • データベースに接続しているときに DBCC DROPRESULTSETCACHE を実行する

データベースを一時停止しても、キャッシュされた結果セットは空になりません。

次のステップ

開発についてのその他のヒントは、開発の概要に関するページをご覧ください。