パフォーマンスの問題があります。
数百万のレコードに入るテーブルがあり、毎秒 100 回このテーブルにアクセスする (選択) Web ページを提供しています。クエリは非クラスター化インデックスでカバーされています (SP にもラップされています)。
私の質問は、パフォーマンスを改善したい特定のシナリオに関するものです。このシナリオでは常に 300 行を生成し、ビューにインデックスを付けてビューにクエリを実行するビューを作成するのが賢明でしょうか。カバーされたクエリで既存の 2M plus テーブルをクエリしますか?
クエリに可能な限り一致するビューを作成し、インデックスを作成できます。私が理解しているように、where句のみを適用したいだけです。これは機能し、where のランタイム コストをゼロに削減します。また、資格のない行のすべての IO を削除します。これは良い考えです。
ただし、フィルター処理された (カバーする) インデックスを使用することもできます。これははるかに簡単です。
カバリング インデックスからの範囲のフェッチは、最高に高速です。それは信じられないほど速いです。改善の余地はありません。
本当の問題は、データベースに何百回もクエリを実行していることです。これらのクエリを 1 つまたは非常に少数のより大きなクエリに折りたたむことはできませんか? テーブル値パラメーターを使用して、いわば複数のクエリ入力を一度に送信できます。
こんにちは、私の理解によると、ここでは常に 300 行を生成する特定のシナリオについて、ビューを作成しています。確実に性能アップ。