問題タブ [indexed-view]

レポートに使用する非常に巨大なテーブルを含む SQL Server 2008 R2 データベースがあります。毎晩、約 40,000 のレコードがテーブルに挿入されます。多くの記事で、インデックス付きビューはトランザクション テーブルではなく、OLAP またはウェアハウス データベースに適していると読みました。

私の目標は、テーブル全体をクエリすることではなく、サブセット、たとえば過去 3 か月のデータをクエリすることです。トリガーを使用してサブセットを作成したくない。インデックス付きビューは私のシナリオに適していますか? そうでない場合、より良いアイデアはありますか？

明らかに、インデックス統計について理解できないことがあります。

ロギング用に数百万行のテーブルがあります。パフォーマンスを向上させるために、ビューとその上に一意のクラスター化インデックスを作成し (最初のインデックスは一意にクラスター化する必要があるため)、非クラスター化インデックスを作成して、インデックスにさらに列を含めることができるようにしました。

次に、これらのインデックスとビューを使用した場合と使用しない場合のクエリのパフォーマンスを比較します。確かに速度が向上し、読み取りと CPU 使用率も低下しているように見えます。

しかし、SQL サーバーが適用した実行計画を見ると、その非クラスター化インデックスのインデックス シークで、一部の列に統計がないという警告が見つかりました。これらの列は where 句にも表示されるため、ここでパフォーマンスを改善する必要があると思います。実行計画が統計がないことについて不平を言っている列が 2 つあります。そのうちの 1 つは非クラスター化インデックス内にあり、もう 1 つはそのインデックスの include 句内にあります。とにかく、これらの統計がまだ欠落している理由がわかりません。

たとえば、http://msdn.microsoft.com/en-us/library/ms190397.aspxでは、「クエリ オプティマイザーは、インデックスの作成時にテーブルまたはビューのインデックスの統計を作成します。」と述べています。さて、私はそれらのインデックスを作成しただけで、それ以来、行は更新または挿入されていません。また、AUTO_UPDATE_STATISTICS と AUTO_CREATE_STATISTICS が有効になっていることも確認しましたが、何が欠けているのでしょうか?

また、SQL Server Management Studio を介してそのインデックスの統計を調べました。は include 節内にありません)。

どうすればこの警告を取り除くことができますか、つまり、これらの統計を作成/強制して存在させることができますか?

この実行計画を見てみましょう: http://sdrv.ms/1agLg7K
これは推定ではなく、実際のものです。約30 分かかった実際の実行から。

2 番目のステートメントを選択します (合計実行時間の 47.8%、約 15 分かかります)。
そのステートメントの一番上の操作を見てください – View Clustered Index Seek over _Security_Tuple4. 操作のコストはステートメントの 51.2% (約 7 分) です。

ビューには約 0.5M 行が含まれています (参考までに、log2(0.5M) ~= 19 – インデックス ツリー ノードのサイズが 2 であることを考えると、わずか 19 ステップであり、実際にはおそらくそれ以上です)。
その演算子の結果はゼロ行です (見積もりとは一致しませんが、今のところ気にしないでください)。
実際の実行 – ゼロ。

問題は、ビープ音が 7 分もかかるのはなぜでしょうか?! （そしてもちろん、どうすれば修正できますか？）

編集：私がここで求めていることについての明確化。「インデックスを調べる」、「サイズを調べる」、「パラメータ スニッフィング」、「異なるデータに対して異なる実行プランを実行する」など、一般的なパフォーマンス関連のアドバイスには興味
がありませ
ん。そのような分析はすべて自分で行います。

私が本当に必要としているのは、ある特定のクラスタ化インデックスのシークが非常に遅くなる原因と、それを高速化するために何ができるかを知ることです。

クエリ全体ではありません。クエリの一部ではあり
ません。
その 1 つの特定のインデックス シークだけです。
編集終了

また、2 番目と 3 番目にコストのかかる操作が、それぞれ _Security_Tuple3 と _Security_Tuple2 に対するシークであり、時間の 7.5% と 3.7% しかかからないことに注意してください。一方、_Security_Tuple3 には約 280 万行が含まれており、これは _Security_Tuple4 の 6 倍です。

また、いくつかの背景：

1. これは、このプロジェクトで不正な動作をする唯一のデータベースです。同じスキーマのデータベースが他にも数十ありますが、この問題が発生するデータベースはありません。
2. この問題が初めて発見されたとき、インデックスが 99% 断片化されていることが判明しました。インデックスを再構築すると速度は向上しましたが、それほど大きくはありませんでした。クエリ全体で、再構築前に 45 分、再構築後に 30 分かかりました。
3. データベースをいじっていると、「select count(*) from _Security_Tuple4」のような単純なクエリに数分かかることに気付きました。なんてこと？！
4. ただし、最初の実行では数分しかかからず、その後はすぐに実行されました。
5. 問題は特定のサーバーや特定の SQL Server インスタンスに関係していません。データベースをバックアップしてから別のコンピューターに復元しても、動作は変わりません。

SQL Fiddle: http://sqlfiddle.com/#!6/d4496/1 (データは実験用に事前に生成されています)

明らかな表があります：

とビュー:

ここで、エンティティ フィールド Classificator1ID..Classificator5ID は分類値 Code1..Code5 に解決されます

このビューには多くのインデックスがあります。

しかし、QO はそれらを使用しないでください。これを試して：

なんで？特に「インクルード」インデックスの何が問題なのですか? インデックスが作成され、すべてのフィールドがあり、まだ使用されていません...

追加: これはただのテストです! あまり怒らないでください。インデックスのメンテナンスの問題を分析するよう私に強要しないでください。

私の実際のプロジェクトでは、QO がインデックス付きビュー (非常に便利なインデックス付きビュー) を無視する理由を説明できません。しかし、時々私はそれが他の場所でそれらを利用しているのを見ます. インデックス式を試すためにこの db スニペットを作成しましたが、もっと何かを行う必要があるかもしれません。

ビューにインデックスを配置しようとしていますが、エラーが発生する問題が発生し続けています

ビューの選択リストには、集計関数またはグループ化列の結果に関する式が含まれているためです。選択リストから集計関数またはグループ化列の結果の式を削除することを検討してください。

コード：

私は SQL Server 2000 を使用していますが、インデックス付きビューの使用を開始するのをためらっています (毎日のパフォーマンス値を含むテーブルがあり、多くの数学関数でそれらをスコアリングする必要があります)。

(パフォーマンス テーブルを使用して) インデックス付きビューを作成し、パフォーマンス テーブルに新しい行を追加した場合、ビューのインデックスはすぐに更新されますか?それともビューの最初のユーザー要求で更新されますか?