問題タブ [indexed-views]

(Sql Server 2008 で) インデックス付きビューを作成すると、必要なすべてのデータをソース テーブルから別の新しいテーブルにコピーすることになりますか? または、このビューを表すために、いくつかの小さなポインター/インデックスのみが保存されますか?

ビューを作成するときに次のエラーが発生します：「ビューをスキーマバインドできません'dbo.viewStock'。'dbo.GetStockCurrentQuantityByProduct'はスキーマバインドされていません。」

背景：私が実際に達成したいのは、商品ID/現在の在庫を取得するクエリの速度を向上させることです。現在の在庫は、特定の製品のユニットイン/ユニットアウトをカウントする関数（'dbo.GetStockCurrentQuantityByProduct'）によって計算されます。私は可能な解決策を模索しています-製品IDと現在の在庫を保持するためのインデックス付きビューを作成し、クエリの実行を高速化するためにそこから直接選択できるようにします。

これを実行すると、次のエラーが発生します。

MS-SQL でインデックス付きビューを分割するにはどうすればよいですか? 値の範囲を格納するインデックス ビューを作成しました。ビューの定義は次のとおりです。

今、日付列を使用してこのテーブルを分割したいと思います。それ、どうやったら出来るの ？

大きなテーブルをテーブルの特定の変換に結合する必要がある、このような状況に頻繁に遭遇します。

大きなテーブルと小さな価格テーブルの例を作成しました。

テーブル CarPrices を入力します。これには、自動車のブランド/モデルごとの価格と、開始日および終了日が含まれています。PriceStartingDate と PriceEndingDate の間の基準 SaleDate で、すべての販売車を CarPrices テーブルの販売価格に結合したいのですが、その期間の価格がない場合は、見つかった最新の価格に結合したいと考えています。

私はこのようにそれを達成することができますが、それは非常に遅いです:

より迅速に行うための確実な方法は、VIEW を作成して代わりにストアド プロシージャを作成することを忘れることです。最初に、正しいクラスター化インデックスを使用して小さな価格テーブルを一時テーブルとして準備し、次にそれに結合します。これははるかに高速です。しかし、私はビューに固執したいと思います。

何かご意見は...？

データベースでインデックス付きビューを使用しています。したがって、クライアントには、それらを呼び出すためのセッション接続設定が必要です。私はado.net接続、コマンドを使用してストアドプロシージャを呼び出しています。ストアド プロシージャを呼び出す必要があるたびに、接続を作成し (接続プールでこれをすばやく実行できることを願っています)、これらの設定を現在の接続に適用するコマンドを実行します。

その他の考え：ストアドプロシージャのすべての呼び出しの前にこれらの設定を追加します：

この解決策はパフォーマンスの問題を引き起こしますね。

毎回新しい接続を作成する必要がある場合、どうすれば余分な作業を避けることができますか? これらの設定を自動的に適用する方法は?

解決：

データは比較的静的であり、パフォーマンスが向上する可能性があるため、ビューにインデックスを付けようとしています。

「ランキングまたは集計ウィンドウ関数」が含まれているため、ビューにインデックスを付けることができません。そのための回避策はありますか？

このビューは、質問に対する学生の回答に試行回数を追加するだけであり、これはインデックス付きビューの完璧なシナリオだと思いましたが、SQL Server はウィンドウ関数を使用したビューのインデックスをサポートしていません。

キャッシュ テーブルを手動で生成することもできますが、これをメンテナンスの手間がかからないようにしたいので、そのようなことを覚えておく必要はありません。

たとえば、おそらく、ベーステーブルが変更されたときにビューをキャッシュテーブルに挿入する何らかのトリガー（トリガーに精通していません）を作成できます...これは基本的に、ビューのインデックスが行うべきことです(ただし、ベース テーブルのデータが変更されたときにインデックスを完全に置き換えるのではなく、インデックスを更新できるため効率が向上します)。

この実行計画を見てみましょう: 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 サーバー 2008 R2。

次のような単純な更新コマンドを実行する

クエリは 1 行しか更新しませんが、2 秒以上かかります。これは、多対多のジャンクションとして使用される 2 つの属性テーブルです。現在、テーブルには約 300 レコードしかありません。主キー = グループおよびユーザー属性の複合キー。

私はそれを調べるために統計を設定しました。クエリの実行には、ビジネスが関与していない他のテーブルが多数含まれています。

私が考えることができる唯一のことは、foobar はインデックス付きビューであり、おそらくそれを維持するためにコストが費やされているということです。そのため、実行計画を確認しました。それは実際に機能します（ただし、コストはわずか 11% です）。

なぜ2秒以上かかるのですか?

私はここで何を見落としていますか？

実行計画では、イベントにインデックスを追加するようにアドバイスされていますが、イベントはここに含まれるべきではなく、コストはわずか 13% です。

何らかの理由で他のテーブルがこれに引き込まれていなければ、これは非常に速いはずだと思います。

インデックス付きビューが一般的な DB オーバーヘッドを増加させることについて、誰かが賢明なアドバイスをくれるでしょう。しかし、他のすべての操作は、インデックス付きビューによって提供される特定のクエリの検索を高速化するために、かなりのコストがかかるように思えます。

教えて; よろしくお願いします！

XML実行計画は大きすぎてテキストとして投稿できず、添付するオプションが表示されないため、pastebinで救助してください：http://pastebin.com/BgjBxLfc

SELECT ステートメントで式を使用して、インデックス付きビューを作成しようとしています。インデックス付きビューの MDSN ガイドラインによると、決定論的である場合は式を使用できます。残念ながら、以下にスクリプト化されたビューに対して一意のクラスター化インデックスを作成しようとすると、以下に示すエラー メッセージが表示されます。式を実行している列は整数データ型に変換されているため、精度の問題もありません。この式が機能しない理由は何ですか?

ビュー '..' にクラスター化インデックス '..' を作成できません。ビューの選択リストに、集計関数またはグループ化列の結果に関する式が含まれているためです。選択リストから集計関数またはグループ化列の結果の式を削除することを検討してください。

ありがとう！