問題タブ [indexed-view]

内部結合と外部結合を持つ3つのテーブルに基づいて、インデックス付きビューを作成します（SQL Server2005）。このビューに対してあらゆる種類のクエリを実行します。したがって、クラスター化するインデックスを選択するための最良の方法は何でしょうか。基準は何ですか、または私を助けるためのツールはありますか？

（私の質問が鈍い場合は申し訳ありませんが、データベースの設計の経験はあまりありません）。

前もって感謝します！

編集：ここで明確にする必要があります。ビューで使用するテーブルは非常に頻繁に使用されており、インデックスの保守にかかるオーバーヘッドはすべて報われる必要があります。

5 つの列 (tableID、CompanyID、UserID、ProjectID、DailyHoursWorked、entryDate) しかない TimeCard という非常に長いテーブル (~3500 万行) があるとします。これは、会社ごと、プロジェクトごと、従業員の 1 日あたりの労働時間を記録する非常に単純な表です。

ここで、特定の会社の従業員の 1 か月あたりのプロジェクトごとの総労働時間を調べるレポートを生成する必要があります。レポートの実行時に必要な集計を実行する代わりに、すべての会社/プロジェクト/ユーザー データが月ごとに集計されたテーブルのようなデータ構造を構築したいので、レポートの実行時にそのデータ構造を直接クエリできます。 3,500 万件までのレコードには数分かかることがあるため、ランタイム集計を実行しません。

だから私は2つの異なる方法があります。(CompanyID、UserID、ProjectID、MonthlyHoursWorked、Month) を列として追加の物理テーブルを作成し、TimeCard テーブルでトリガーを使用して、追加のテーブルの値を変更します。または、インデックス付きビューを作成できます。なので両方試しました。最初に、次のコードでインデックス付きビューを試しました。

インデックス付きビューが正しく作成され、合計で合計 500 万行に達しました。

ただし、毎回 SQL キャッシュをクリアして次のクエリを実行すると、*select * from vw_myView where companyID = 1*、ほぼ 3 分かかります。上記のように追加のテーブル ルートを使用すると、キャッシュがクリアされた状態で、約 4 秒かかります。

私の質問は、インデックス付きビューはこの特定のシナリオでは悪い選択ですか? 特に、基になるテーブル (TimeCard) が変更されるたびに、またはそれに対してクエリが実行されるたびに、インデックス付きビュー全体が再計算/再集計されるかどうかを知りたいですか?

ありがとう！

MySQL には、SQL Server の「インデックス付きビュー」機能と同等のものがありますか?

ビューは単純なクエリよりも高速ですか?

私が特に探しているのは、下線付きのビューのクエリ/SQL を単に実行するよりも速く結果を返す「ビュー」を MySQL が作成する方法です。

次のようなテーブルを含むスキーマがあります (疑似スキーマ):

ItemCollectionId ごとに個別の貢献者の数を集計する必要があります。これは、次のようなクエリで可能です。

さらに、インデックス付き (マテリアライズド) ビューを使用して、この集計を事前に計算したいと考えています。DISTINCT は、このビューにインデックスが配置されるのを防ぎます。SQL Server のインデックス付きビューの制約に違反しない、これを再定式化する方法はありますか?

OK、SQL Server のインデックス付きビューについて混乱しています (2008 を使用)

私はと呼ばれるインデックス付きビューを持っています

課題の詳細

の実行計画を見ると

インデックス付きビューが抽象化することになっている他のすべてのテーブルのすべての基になるインデックスの実行計画を示しています。

実行計画は単に PK_AssignmentDetail (ビューのクラスター化インデックスの名前) のクラスター化インデックス スキャンになると思いますが、そうではありません。

このインデックス付きビューではパフォーマンスが向上しないようです。どうすればよいですか? 他のすべてのインデックスにヒットする必要がないように、すべての列を含む非クラスター化インデックスも作成する必要がありますか?

どんな洞察も大歓迎です

Oracleは、マテリアライズド・ビューに対していくつかのリフレッシュモード・オプションを提供していることを知っています（オンデマンド、コミット時、定期的）。Microsoft SQLServerは、インデックス付きビューに対して同じ機能を提供しますか？

そうでない場合、データを毎日+オンデマンドでエクスポートすることが目的であり、パフォーマンスのオーバーヘッドの問題を回避したい場合、SQLServerでインデックス付きビューを使用するにはどうすればよいですか？回避策はありますか？

SQL Server 2008 R2 がクエリへの結合を含むインデックス付きビュー (マテリアライズド ビューとも呼ばれます) を自動的に照合できる場合の経験はありますか?

たとえば、ビュー

まったく同じクエリに自動的に一致させることはできません。このビューから直接選択すると、with (noexpand)実際には、インデックス付きビューのクラスター化インデックスをスキャンするはるかに高速なクエリ プランが得られます。SQL Server にこのマッチングを自動的に行わせることはできますか? かなりの数のクエリとビューがあり、OR マッパーを使用しているため、インデックス付きビューを毎回手動で参照したくありません。

SQL Server 2008 R2 のエンタープライズ エディションを使用しています。

編集：解決策を見つけました。SQL Server 2008 R2 は、3 つ以上の結合を持つインデックス付きビューを自動的に照合しません。おそらく、最適化プロセスが非常に遅くなるでしょう。

編集 2: 質問が私によって作成されてから 2 年後にこれを確認すると、私の結論は正しくないと思います。マテリアライズド ビューのマッチングは非常に脆弱なプロセスであり、何年にもわたって見つけた明確なルールはありません。

確かに、次のような役割があります。

• 結合数
• 述語の存在
• ビューとクエリの両方での結合順序

私の要件: インデックス タイトルがアルファベットの開始文字であるインデックス付きテーブル ビューに、人の名前をアルファベット順にリストするという単純な要件があります (さらに、上部に検索アイコンと、数字で始まるその他の値を表示するための # があります)。およびその他の特殊文字)。

これまでに行ったこと: 1. ストレージにコア データを使用しており、「last_name」は連絡先エンティティの文字列プロパティとしてモデル化されています 2. NSFetchedResultsController を使用して、並べ替えられたインデックス付きテーブル ビューを表示しています。

要件を達成するための問題: 1. まず、セクション インデックスのタイトルをアルファベットの最初の文字にすることができませんでした。次の投稿でのデイブの提案は、同じことを達成するのに役立ちました:文字列の最初の文字によって作成されたセクションを持つ NSFetchedResultsController

Dave の提案で遭遇した唯一の問題は、"#" インデックスの下にグループ化されたその他の名前を取得できなかったことです。

私が試したこと: 1.カスタム比較メソッドを NSString (カテゴリ) に追加して、比較とセクションがどのように行われるかを確認しようとしましたが、NSSortDescriptor セレクターで指定されたときにそのカスタムメソッドが呼び出されません。

ここにいくつかのコードがあります：

データを取得するコード:

不足しているものと、要件をどのように達成できるか教えていただけますか?

これが私の構成です：

• データベースの更新に使用する再実行可能なバッチ スクリプトがあります。
• そのバッチ スクリプト内には、次のようなコードがあります。
  • テーブル 'A' が存在しない場合は、テーブル 'A' を作成し、そこに行を挿入します。
• そのバッチ スクリプトの後半で、そのテーブルにスキーマ バインドされたインデックス付きビューを作成します。
  • ご存じないかもしれませんが、インデックス付きビューには特定のクライアント設定が必要です。

• 場合によっては、テーブルが作成された後にスクリプトを再実行すると、SQL Server Management Studio は、「このテーブルが存在しない場合」コードによって保護されている「行の挿入」コードを評価し、次のエラー:

  メッセージ 1934、レベル 16、状態 1、行 15 INSERT は、次の SET オプションの設定が正しくないため失敗しました: 'CONCAT_NULL_YIELDS_NULL, ANSI_WARNINGS, ANSI_PADDING, ARITHABORT'. 計算列のインデックス付きビューやインデックス、フィルター選択されたインデックス、クエリ通知、XML データ型メソッド、空間インデックス操作で使用する SET オプションが正しいことを確認します。

• 注: 誰かがこの INSERT ステートメントを単独で試した場合、SSMS がこのエラーを生成する と完全に予想されます。
  • ただし、条件付きブロックによって保護されている場合はそうではありません。

私の質問：

SSMS コンパイラは、実際に実行されるかどうかに関係なく、すべての式を評価しますか?

インデックス付きのビューがあり、それを適切に実行するには、noexpandヒントを指定する必要があります。残念ながら、NOLOCKヒントからLinq to SQLで生成されたT-SQLクエリを変更することに関して見られるように、これらのヒントを直接利用する簡単な方法はないようです。

私の考えでは、属性を使用するか、宣言的にdbmlを使用して、このようなものをカスタマイズできるようにすることは理にかなっています。また、Linq toSQLはSQLServerを対象としてのみ機能するように見えるため、これらの高度な機能（存在する場合）も活用できることは理にかなっています。実装に関係なく、私はこの問題を解決するための創造的な方法に興味があります。