インデックスを作成するよりも統計を作成する方が良い場合はいつですか？
whatSTATISTICSに関する多くの情報が見つかりました。それらをどのように維持するか、それらをクエリまたはインデックスから手動または自動で作成する方法などです。しかし、whenに関するanyガイダンスまたは「ベストプラクティス」情報を見つけてそれらを作成することができませんでした。インデックスよりも手動で作成したSTATISTICSオブジェクトのほうがメリットがある状況はどれですか。パーティション化されたテーブルでのクエリに役立つ手動で作成されたフィルター処理された統計を確認しました（インデックスに対して作成された統計はテーブル全体をカバーし、パーティションごとではないため-目立たない！）インデックスの詳細を必要とせず、インデックスを維持するコストや、ブロック/デッドロックの可能性を高める価値もありません。
@JonathanFiteはコメントで、インデックスと統計の違いについて言及しました：
インデックスは、テーブル自体とは異なる方法でソートされるルックアップを作成することにより、SQLがデータをより速く見つけるのに役立ちます。統計は、SQLがクエリを満たすために必要なメモリ/作業量を決定するのに役立ちます。
これはすばらしい情報です。主に、質問を明確にするのに役立ちます。
これ（またはwhatsおよびhowsに関するその他の技術情報、および動作に関連するその他の技術情報）を知る方法STATISTICSの性質）whenを決定するのに役立ちますCREATE STATISTICS以上CREATE INDEX、特にインデックスを作成すると、関連するSTATISTICSオブジェクトが作成されますか？onlySTATISTICS情報とnotインデックスを持つことで、どのシナリオがより適切に提供されますか？
可能であれば、STATISTICSオブジェクトがINDEXよりも適しているシナリオの実用的な例があると、非常に役立ちます。
私は視覚的な学習者/思想家なので、STATISTICSとINDEXesの違いを並べて表示すると、STATISTICSの方が適切な場合を判断するのに役立つ可能性のある手段として役立つと思いました。
Thingy PROs CONs
------- ---------- -------------------
INDEX * Can help sorts. * Takes up space.
* Contains data (can * Needs to be maintained (extra I/O).
"cover" a query). * More chances for blocking / dead-locks.
STATISTICS * Takes up very little space. * Cannot help sorts.
* Lighter maintenance / won't * Cannot "cover" queries.
slow down DML operations.
* Does not increase chances
of blocking / dead-locks.
以下は、これを探しているときに見つけたいくつかのリソースです。この同じ質問をすることさえありますが、答えられませんでした：
SQL Serverの統計に関する質問は恥ずかしがり屋でした
**明確にするために、私はこれに対する答えはありません。実際に、インターウェブで奇妙な情報が不足しているように見える情報を提供するために、できれば少数の人々からフィードバックを得たいと思っています。
あなたが質問を中心に展開します-統計を作成するのとインデックスを作成する（統計を作成する）だけのほうがいいのはいつですか？
私のsql server internals notes（SQLSkills class- IE1 and IE2）および SQL Server internals book から、以下は私のlimited理解です：
SQL Serverの統計は、インデックスキーの値と通常の列の値に関する重要な情報を含むシステムオブジェクトにすぎません。
SQL Serverは、コストベースのモデルを使用して、「十分な」実行プランを可能な限り迅速に選択します。カーディナリティの推定（クエリ実行の各ステップで処理される行数の推定）は、クエリ最適化の最も重要な要素であり、データにアクセスするときの結合戦略、メモリ許可要件、ワーカースレッドの選択、およびインデックスの選択に影響します。 。
SQL Serverは、それが大きいと推定する場合、非クラスター化インデックスを使用しません。 KEYまたはRIDのループアップ操作が必要になるため、そのような推定に役立つインデックス（および列）の統計を維持します。
統計には2つの重要な点があります。
ヒストグラムには、左端の統計（インデックス）列のみのデータ分布に関する情報が格納されます。また、キー値の複数列の密度に関する情報も格納します。したがって、基本的に、ヒストグラムは左端の統計列のみのデータ分布を格納します。
SQL Serverは、テーブルサイズに関係なく、ヒストグラムで最大200ステップを保持します。各ヒストグラムのステップでカバーされる間隔は、テーブルが大きくなるにつれて増加します。これにより、大きなテーブルでは「精度の低い」統計が発生します。
インデックスの選択性は密度に反比例するメトリックであることを忘れないでください。つまり、列が持つ一意の値が多いほど、その選択性は高くなります。
特定のクエリがあまり頻繁に実行されない場合は、インデックスではなく列レベルの統計を作成するように選択できます。列レベルの統計は、クエリオプティマイザーが適切な実行プランを見つけるのに役立ちます。ただし、これらの実行プランは、インデックススキャンが関係しているために最適ではありません。同時に、統計はデータ変更操作中にオーバーヘッドを追加せず、インデックスのメンテナンスを回避するのに役立ちます。このアプローチは、ほとんど実行されないクエリに対してのみ機能します。
参照：
- 列統計はオプティマイザにエッジを与える by Kalen Delaney
- Statistics、Damned Lies、and Statistics – What Statman？ by Conor Cunningham
注： Paul White または Aaron Bertrand のような人は、 あなたの良い質問 。
データ量を制限したり、フィールドに基づいて正しいデータにすばやくアクセスしたりできるようにする必要がある場合は、インデックスが必要だと思います。
オプティマイザーがデータの性質を理解して、可能な限り最良の方法で操作を実行できるようにする必要がある場合は、統計が必要です。
私が理解したことは、フィルターされた統計は、データに偏りがあり、計画に大きな影響を与える場合に役立ちます。たとえば、スタックオーバーフローでは、少数のユーザーが膨大な数の投稿を持っているため、ユーザーあたりの平均投稿だけを使用することは、実際には最善の見積もりではありません。したがって、ユーザー名に基づいてuserIdにフィルタリングされた統計を作成すると、SQL Serverは、このユーザー名がクエリに含まれている場合、これが取得するユーザーIDであることを認識し、それを把握できるはずです。ポストテーブルのインデックスフィールドには、ヒストグラムが存在するため、そのIDを持つ行が大量にあります。平均では、それを行うことはできません。
70-461からItzik Ben-Ganによるトレーニングブック
統計を手動で作成する理由はいくつかあります。 1つの例は、クエリ述語に列間関係を持つ複数の列が含まれている場合です。複数の列の統計は、クエリプランの改善に役立ちます。複数の列の統計には、単一列の統計では利用できない列間密度が含まれています。ただし、列がすでに同じインデックスにある場合、複数列統計オブジェクトはすでに存在しているため、手動で追加の統計オブジェクトを作成しないでください。