SQL Serverが複合列統計ヒストグラムを実行しないのはなぜですか？

SQL Serverには「マルチカラム統計」と呼ばれるものがありますが、それが意味するものとは異なります。

次のサンプルテーブルを見てみましょう。

CREATE TABLE BadStatistics 
(
    IsArchived BIT NOT NULL,
    Id INT NOT NULL IDENTITY PRIMARY KEY,
    Mystery VARCHAR(200) NOT NULL
);

CREATE NONCLUSTERED INDEX BadIndex 
    ON BadStatistics (IsArchived, Mystery);

これで、2つの統計が2つのインデックスで作成されています。

BadIndexの統計：

+--------------+----------------+-------------------------+
| All density  | Average Length | Columns                 |
+--------------+----------------+-------------------------+
| 0.5          | 1              | IsArchived              |
+--------------+----------------+-------------------------+
| 4.149378E-06 | 37             | IsArchived, Mystery     |
+--------------+----------------+-------------------------+
| 4.149378E-06 | 41             | IsArchived, Mystery, Id |
+--------------+----------------+-------------------------+

+--------------+------------+---------+---------------------+----------------+
| RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | DISTINCT_RANGE_ROWS | AVG_RANGE_ROWS |
+--------------+------------+---------+---------------------+----------------+
| 0            | 0          | 24398   | 0                   | 1              |
+--------------+------------+---------+---------------------+----------------+
| 1            | 0          | 216602  | 0                   | 1              |
+--------------+------------+---------+---------------------+----------------+

クラスター化インデックスの統計：

+--------------+----------------+---------+
| All density  | Average Length | Columns |
+--------------+----------------+---------+
| 4.149378E-06 | 4              | Id      |
+--------------+----------------+---------+

+--------------+------------+---------+---------------------+----------------+
| RANGE_HI_KEY | RANGE_ROWS | EQ_ROWS | DISTINCT_RANGE_ROWS | AVG_RANGE_ROWS |
+--------------+------------+---------+---------------------+----------------+
| 1            | 0          | 1       | 0                   | 1              |
+--------------+------------+---------+---------------------+----------------+
| 240999       | 240997     | 1       | 240997              | 1              |
+--------------+------------+---------+---------------------+----------------+
| 241000       | 0          | 1       | 0                   | 1              |
+--------------+------------+---------+---------------------+----------------+

（私は、約10分の1の行がアーカイブされていないランダムなサンプルデータをテーブルに入力しました。その後、フルスキャン統計の更新を実行しました。）

2列の統計のヒストグラムで1列しか使用されないのはなぜですか？多くの人がそれについて書いていることを知っていますが、その根拠は何ですか？この場合、最初の列には2つの値しかないため、ヒストグラム全体の有用性は低くなります。なぜ統計がそのように恣意的に制限されるのでしょうか？

この質問は、完全に異なる獣である多次元ヒストグラムについて言及していないことに注意してください。これは、1次元のヒストグラムに関するものであり、1次元は、それぞれの複数の列を含むタプルです。

バックグラウンド

現在のSQL Serverモデルは、単一列のヒストグラムと複数列の密度情報のみを使用します。単一列ヒストグラムは、適切な述語などに対する選択性を推定するために使用されていますa = 1かb > 50。複数の述語を使用するクエリは、個々の選択性を（仮定を使用して）単純に組み合わせて、推定全体の選択性を生成します。

例については、私の記事「カーディナリティの推定：密度統計の結合」を参照してください

複数列の密度は、複数の等式述部に弱い相関情報を提供し、集計にカーディナリティをグループ化することで、モデルにさらに情報を提供します。

インデックスに関連付けられた統計は、そのモデルに対する日和見的なアドオンです。エンジンは、インデックスの構築中に（通常はフルスキャン）統計を収集することもあります。SQL Serverは、他のキーの先行列ヒストグラムと密度情報を自動的に作成します。

インデックスの非先行列のヒストグラムは、クエリプロセッサによって自動的にオンデマンドで構築されるか、事前に（他のオプションと共に）オプションを使用sp_createstatsして構築されます@indexonly。

複数列のヒストグラム

（上記のように）単一列統計を組み合わせるときに行われる仮定は、データの現実を十分にモデル化できる場合とそうでない場合があります。多くの場合、利用可能なオプション（指数バックオフ、独立性、最小選択性）は、「十分に良い」推定値を生成します。

また、質問の例のように、カーディナリティが低い列の主なインデックスに対する自然な解決策として、統計（およびインデックス）をフィルタリングしました。これらを論理的な極端にすると、問題ではない多次元統計により近づくことができます。

利用可能なモデリングオプションが適切な推定を提供できない場合、複数列の統計ヒストグラムは実際に、適切なインデックス述語に対してより優れた選択性推定を提供する場合があります。異なる列で異なるデータ型を組み合わせるのは困難ですが、克服できないことはありません。

インデックスキーの各レベルのヒストグラムも必要です（最良の結果を得るには）。したがって、それに関するインデックスは、現在の単一列のヒストグラムだけでなく(a, b, c)、(a, b)それ(a, b, c)に加えてヒストグラムも意味します(a)。

古くなった統計の検出に使用されるメカニズムも、影響を受ける複数列のヒストグラムを維持するために変更する必要があります。これらのヒストグラムは、単一の列の統計よりも頻繁に再構築される可能性が高くなります。これは、より多くの列への変更が影響を与えるためです。

これらすべてにより、サイズ、複雑さ、およびメンテナンスのオーバーヘッドが追加されます。

複数の列を参照する慎重に作成された計算列で作成された統計を使用して、複数列の統計を（限られた範囲で）シミュレートできます。クエリは、その統計を利用するために、計算された列に述語（または基になる数式の完全なテキスト一致）を含める必要があります。このアプローチが実用的である状況はおそらく非常に限られています。それでも、自動マルチカラムヒストグラムと同じ実装の問題がいくつかあります。

結局のところ、SQL Serverが複数列統計をサポートしていない理由を確信できるのは、設計者自身だけです。この分野の製品の改善について幅広い適用性を持つ強力な主張をすることができると思われる場合は、Connectまたは通常のサポートチャネルを介して提案することができます。

脚注

この場合、最初の列には2つの値しかないため、ヒストグラム全体の有用性が低くなります。

ヒストグラムは、まだ先頭列の値の分布に関する有用な情報を提供します：統計が建設されたとき、そこに24398行あっIsArchivedた偽のだっれる216602行、そして真が。

さらに、統計オブジェクトは、（1 / 0.5）= 2の個別の値がIsArchived（1 / 4.149378E-06）〜= 241000の個別の値で(IsArchived, Mystery)あり、平均行サイズが37バイトであり(IsArchived, Mystery, Id)、行ごとに4バイト追加。

これは、他の列に関する統計情報と組み合わせて、複数の述語（前述）を使用したクエリで選択性推定を生成できる、汎用的な優れた情報です。