次の方法で共有

式に対するカーディナリティ推定 (CE) のフィードバック

適用対象:適用対象: SQL Server 2025 (17.x) プレビュー Azure SQL DatabaseSql データベース (Microsoft Fabric プレビュー)

カーディナリティの推定が不正確な場合、クエリの最適化中にパフォーマンスが低下することがよくあります。 式のカーディナリティ推定 (CE) フィードバックは、CE フィードバック機能によって開始されるフレームワークを拡張します。 目標は、繰り返し式のカーディナリティ推定を改善することです。 式機能のフィードバックは、クエリ間での式の以前の実行から学習し、適切な CE モデルの選択肢を見つけ、それらの式の将来の実行に学習した内容を適用します。 CE フィードバックと同様に、モデルの推奨事項はテストされ、今後のクエリ実行に自動的に適用されます。

式機能のフィードバックは、特定のクエリの式とデータ分散に適した モデル の仮定を識別して使用します。その結果、クエリ実行プランの品質が向上します。 現在、式機能のフィードバックでは、推定行数と実際の行数が大きく異なるプラン演算子を特定できます。 重要なモデル推定エラーが発生し、実行可能な代替モデルがある場合は、クエリ内の式にフィードバックが適用されます。

データベース エンジンのバージョンが異なると、データの分散方法とクエリ方法に基づいて、 異なる CE モデルの前提条件が使用されます。

「CE フィードバック」を表現に使用する

式に対する CE フィードバックは、クエリの実行を監視し、カーディナリティの誤推定が一貫して発生する部分式を特定します。 フィードバックは、観察されたパターンに基づいて生成され、推定精度を向上させるためにクエリのコンパイル中に適用されます。

前提条件と構成

式に CE フィードバックを使用するには、次の前提条件を満たす必要があります。

  • データベースは 互換性レベル 160 以降を使用する必要があります。
  • CE_FEEDBACK_FOR_EXPRESSIONSデータベース スコープの構成を有効にする必要があります (既定で有効)。
  • データベース スコープ構成の現在の状態を確認するには:
SELECT name,
       value,
       value_for_secondary
FROM sys.database_scoped_configurations
WHERE name = 'CE_FEEDBACK_FOR_EXPRESSIONS';

この機能は、次のデータベース スコープ構成コマンドを使用してデータベースで有効にすることができます。

ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK_FOR_EXPRESSIONS = ON;

データベースの式機能のフィードバックを無効にするには、 CE_FEEDBACK_FOR_EXPRESSIONS データベース スコープの構成を無効にします。

ALTER DATABASE SCOPED CONFIGURATION SET CE_FEEDBACK_FOR_EXPRESSIONS = OFF;

動作方法

指紋は SQL Server データベース エンジンの新しい概念ではありませんが、式のフィードバック機能のコンテキストでの 指紋 とは、式内からの計算されたシグネチャの組み合わせを指します。 たとえば、架空のビジネスのビジネス アナリストは、顧客が 10,000 ドルを超える金額を費やした顧客の注文に関する情報を取得できます。 Orders テーブルにも結合されている Customers テーブルからデータを収集する select ステートメントは、この種類のデータを表示する 1 つの方法です。

SELECT *
FROM Customer AS C
     INNER JOIN Orders AS O
         ON C.custkey = O.o_custkey
WHERE O.o_totalprice > 10000;

このクエリでは、クエリ オプティマイザーは、各テーブルからデータを取得することを選択できます(Customer、その後にOrders、両方のテーブルから関連付けられているすべての列を選択し、注文のが $10,000 を超えるデータを (フィルターを使用して) totalpriceします。 クエリ プラン内のフィルターや結合などの各論理式は、指紋に寄与するシグネチャを生成します。 式の CE フィードバックでは、これらのフィンガープリントを使用して、全体的なクエリ構造が異なる場合でも、同様の部分式を共有するクエリ間でフィードバックを学習し、適用します。

この機能では、クエリ全体でカーディナリティの過大評価/過小評価が一貫した式に焦点を当てています。 現在 CE フィードバックの対象ではない 2 つの異なるワークロード パターンが分析されます。

  • 繰り返し実行せずに、繰り返し式パターンを持つワークロード。 たとえば、一般的に使用される結合パターンなどです。

  • クエリの一部が、同じクエリの別の部分とは異なる CE モデルの恩恵を受ける可能性があるクエリ。 たとえば、テーブル A と B の間の結合には単純な包含が必要な場合があり、テーブル間の結合には C と Dがあり、基本包含が必要になる場合があります。

式機能のフィードバックは、フィルターと結合の前提条件を適用して、次のような誤った問題を修正します。

Filters:

  • ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES
  • ASSUME_PARTIAL_CORRELATION_FOR_FILTER_ESTIMATES
  • ASSUME_FULL_INDEPENDENCE_FOR_FILTER_ESTIMATES

Joins:

  • ASSUME_JOIN_PREDICATE_DEPENDS_ON_FILTERS
  • 基本的な封じ込めの仮定 (ヒントを渡す必要がない)

これらの前提条件は、封じ込めや独立性など、さまざまな CE モデル戦略を反映しています。 概念的背景の詳細については、 ケイト・スミスが説明したカーディナリティ推定フィードバック と 、SQL Server 2016 の相関列のカーディナリティ推定を参照してください。

ヒントのライフサイクル

フィードバック ヒントは、次の状態で進行します。

  • 監視: システムは部分式の繰り返し実行を監視し、カーディナリティの誤りが持続するかどうかを追跡します。
  • 適用: 誤った評価が続く場合は、CE モデルを調整するために、クエリのコンパイル中にフィードバック ヒントが生成され、適用される可能性があります。
  • ブロック: 適用されたヒントの結果、カーディナリティの推定が最適でない場合は、今後の使用がブロックされます。

このライフサイクルにより、フィードバックは有益な場合にのみ適用され、推定品質の回帰を回避できます。

回帰保護

CEフィードバックには回帰の保護が含まれます。 ヒントによってカーディナリティの推定が以前よりも悪くなる場合、ブロックされます。 ただし、この保護はカーディナリティ推定に限定され、クエリの実行時間は評価されません。 実行/ランタイム関連の回帰の場合、 自動プラン修正 が介入する可能性があります。 プランの自動修正機能が有効になっていない場合は、 sys.dm_db_tuning_recommendations動的管理 ビューに対してクエリを実行することで、機能が実行するアクションが記録され、使用できるようになります。

テレメトリと監視

式に関する CE フィードバックアクティビティは、次のツールを使用して監視できます。

  • 拡張イベント:
    • adhoc_ce_feedback_query_level_telemetry
    • query_adhoc_ce_feedback_expression_hint
    • query_adhoc_ce_feedback_hint

CE フィードバックの拡張イベントの query_ce_feedback_begin_analysis と query_ce_feedback_telemetry は、機能のアクティビティを追跡するときにも役立ちます。

  • 指紋データは、 AdHocCEFeedbackCacheという名前の専用メモリ クラークにキャッシュされます。 このキャッシュには、システム カタログ ビュー sys.dm_exec_ce_feedback_cache経由でアクセスできます。

  • プラン表示の統合

    式ヒントの CE フィードバックが適用されると、クエリ プランには showplan XML に CardinalityFeedback 属性が含まれます。 このタグは、特定の部分式のカーディナリティ推定を調整するためにフィードバックが使用されたことを示します。

キャッシュと永続化

永続化されたフィードバックは、内部クエリ ストア テーブル (sys.plan_persist_ce_feedback_for_expressions) に格納され、起動時に再読み込みされます。 これにより、システムが既に検出した指紋のフィードバックを再学習する必要がないようにします。 キャッシュ永続化メカニズムはその性質上、情報が失われやすく、フィードバックは定期的にディスクに保存されます。 永続化の頻度は現在構成できません。

SQL Server インスタンスが再起動するか、次の永続化サイクルの前にメモリがクリアされると、最後のフラッシュ以降に生成されたフィードバックが失われる可能性があります。

Limitations

現在、読み取り可能なセカンダリのクエリ ストアでは永続化を使用できません。 式の CE フィードバックは、プライマリ レプリカとセカンダリ レプリカで異なる方法でフィードバックを適用できます。 ただし、フィードバックはセカンダリ レプリカに保持されず、そのシナリオではメモリ ベースのキャッシュ内にのみ存在します。 フェールオーバー イベントが発生した場合、読み取り可能なセカンダリのいずれかで学習されたフィードバックは失われます。

関連コンテンツ

  • Last updated on