問題タブ [indexed-view]

私はSQLServer2008を使用していて、インデックス付きビューの使用がクエリの一部を高速化するのに役立っていることに気付き始めました...スキーマが基本的ではないためです。

だから、私が次のようなテーブルを持っている場合...

したがって、親テーブルの各行には、0から多数の子を含めることができます。

まず、子のインデックス表示を作成した場合、提出されたParentIdがnull許容である可能性がある場合は機能しません。だから私はそれを必須にする必要があります。

さて、質問です。

親テーブルに内部結合された子テーブルのインデックスビューがあります（どちらかのテーブルの一部のフィールドのみにインデックスを付けていることに注意してください）...

さて、これらの5つのフィールドのデータは、別の場所にシリアル化/コピーされていますか？または、インデックスビューは、テーブルのデータである一部のインデックスIDのみを作成しますか？

クエリを最適化する方法について質問があります。実際、クエリを頻繁に実行する予定なので、具体化されたビューまたはインデックス付きビューを使用するか (これは良い考えですか?)、非正規化することを考えていました。

次の 4 つのテーブルを考えてみましょう (無関係なフィールドは省略されています)。

• ユーザー (int userId)
• グループ (int groupId)
• GroupMemberships (int userId、int groupId、bool isSharing)
• コンピュータ (int userId)

この関係は、ユーザーが 0..n 台のコンピューター (1 人のユーザーから多数のコンピューター) を持つことができ、0..n グループのメンバーになることができるということです。グループには 0..n 人のユーザー (多数のユーザーから多数のグループ) を含めることができます。「isSharing」は、ユーザーがそのグループと共有しているか、そのグループの「読み取り専用」メンバーであるかを示します (つまり、共有メンバーのコンピューターを表示できますが、自分のコンピューターは共有しません)。

クエリは、特定のユーザーについて、そのユーザーが表示できるコンピューターを見つけることです。ユーザーは、自分のすべてのコンピューターを表示できます。彼女はまた、彼女がメンバーであり、そのグループと共有しているグループに属している他のユーザーのコンピューターも見ることができます。さて、それはあまり意味がないので、O(n^3) 疑似コードの目標は次のとおりです。

現在、私は ORM マッパーを使用しており、基本的に上記のことを行っています (SQL のことはあまり得意ではありません) が、それは明らかに理想的とは言えない解決策です。そこにリストしたすべてのフィールド (isShared を除く) にインデックスがあり、GroupMembership の (userId, groupId) タプルに追加のインデックスがあります。しかし、データベースの専門家がより良い解決策を思い付くことができるでしょうか?

プロジェクトはまだ稼働していませんが、ユーザーあたり平均 1.2 台のコンピューター (全員が 1 台、一部はそれ以上のコンピューターを所有する可能性があります) であり、ユーザーあたりのグループ メンバーシップはおそらく 0.75 になると思います (多くのユーザーはグループを使用しません)。機能ですが、そうする人は複数のグループのメンバーになる可能性があります)。また、これらの関連付けられたテーブルはすべて頻繁に追加されるため、マテリアライズド ビューの実用性が低下する可能性があります。SQL Server 2008 を使用しています。

ありがとう、万歳、ロバート

サーバー: MS SQL Server 2008

インデックス付きビューを作成し、ビューのスキーマを変更すると、インデックスがすべて削除されます。

それはとても迷惑です！

誰かがこれがなぜなのか説明できますか? 最初は、インデックスが必要とするフィールドがもはやスキーマにないためではないかと考えました (変更しただけですよね?) .... しかし、インデックス フィールドがビュー schema にあるときはいつでも。 ..そこにインデックスを残すだけです。

とにかく..暴言暴言...

誰かがこれについて内部の知識を持っていることを願っています.

SQL Server 2005 には、インデックス フィルターと呼ばれる新しい機能があるとのことでした。

私がしたいのは、列にインデックスを追加し、インデックスに null 値を無視させることです。

この機能に関する適切な情報が見つかりません (ソースが間違っている可能性があります)。誰でもこの機能に関する追加情報を提供できますか?

ビューのインデックスがどのように機能するかを簡単な英語で説明してもらえますか? 私は、テーブルのインデックスについてかなり簡単に理解しています。ビューのインデックス作成は、基礎となるテーブルのインデックスに自然に任せることとどのように異なるのでしょうか?

MS SQL Server 2008 でインデックス付きビューを使用した経験のある人はいますか? インデックス付きビューで使用されているテーブルの行を追加/更新する挿入/更新ステートメントのパフォーマンスにインデックス付きビューがどのように影響するかを調べようとしています (インデックス付きビューがいくつかのテーブルを結合する選択であると仮定します)。ビューの基礎となる選択の結果であるすべてのデータがインデックス付けされていることを考えると、何かが追加/変更されたときにそれらのインデックス付けされたデータを更新する舞台裏の「トリガー」が必要であると推測しています。ただし、この問題に関する有用な情報を見つけることができませんでした。

3つの大きなテーブルにまたがるインデックス付きビューがあります。これらのテーブルの2つ（AとB）は、ユーザートランザクションで常に更新されており、もう1つのテーブル（C）には、週に1回更新する必要のあるデータ製品情報が含まれています。この製品テーブルには、600万を超えるレコードが含まれています。

コアビジネスプロセスでは、これら3つのテーブル全体でこのビューが必要ですが、残念ながら、この側面を変更することはできません。負荷がかかった状態でテストして、最も効率的な構成になっていることを確認するために、SQLサーバーMVPを導入しました。ビューで使用される製品テーブルには1つの列があり、毎週更新する必要があります。

現在発生している問題は、テーブルAおよびBに対するトランザクションの量が増加しているため、テーブルCの更新によってデッドロックが発生していることです。

私はいくつかの異なる方法を試しましたが、役に立ちませんでした。1）テーブルCが「WITH（NOLOCK）」というダーティな読み取りになるようにビューを変更できることを望んでいましたが、インデックスビューでは機能が利用できないようです。

2）表Cの新しい列を更新し、プロセスが完了したときに名前を変更することを考えましたが、ビューの依存関係のためにそれを行うことはできません。

3）また、この値を一時的な製品テーブルに書き込み、ビューに対してALTERステートメントを実行して、新しいテーブルを指すようにするというアイデアも楽しみました。ただし、これを行うと、ビューのインデックスが削除され、再作成にかなりの時間がかかりました。

4）毎週の更新を小さなチャンク（一度に100レコード程度）で実行しようとしましたが、それでもデッドロックが発生します。

質問：

a）SQL Server 2005を使用しています。SQLServer2008には、インデックス付きのビューを備えた新しい機能があり、役に立ちますか？インデックス付きビューを使用してダーティリードを実行する方法はありますか？

b）新しいテーブルを指すように既存のビューを変更するためのより良いアプローチ？

ありがとう！

インデックス付きビューを作成しました:

SQL 2005 Standard SP3 では、フルテキスト インデックスがビューのすべての行に対して次のクエリを実行するため、そのビューにフルテキスト インデックスを作成するのに非常に時間がかかります。

COLUMN FULLTEXTALLとCOLUMN FULLTEXTKEYは実際にはValueとであると思いIDますが、それが SQL Server Profiler の表示です。問題は、クエリ プランがビューのインデックスを使用しないため、約 11M 行/1 GB のデータに対してクラスター化インデックス スキャンを使用することです。そのクエリのプラン ガイドを作成しようとしましたが、標準の T-SQL クエリではないため、許可されません ( Incorrect syntax near the keyword 'FULLTEXTKEY')。

このフルテキスト インデックスを次の方法以外で動作させる方法はありますか。

• 正常に動作する SQL 2008 (または SQL 2005 Enterprise) にアップグレードします。
• 基になるテーブルに一意の ID とカバ​​ー インデックスを作成します。

アップグレードにはサーバーのダウンタイムが必要であり、一意の ID を作成している間に新しい SQL Server ライセンスが必要になる可能性があり、11M 行のサブセットのみがフルテキスト インデックスを必要とするため (LRVS_VALUE多くの場合NULL、または非常に短いテキストを持っているため)、カバーするインデックスは多くのスペースを浪費します。価値）。

ビューのカウント列に問題があります。

クエリは、次の MSDN の例に似ています: http://msdn.microsoft.com/en-us/library/ms191432.aspx

ビューをコンパイルしようとすると、「無効な列名 ModuloColAColB」のようなエラー メッセージが表示されました。

だから私は列名でグループを変更します：

ビューは正しくコンパイルされていますが、インデックスを追加しようとすると次のエラーが表示されます。

「ColumnA % ColumnB AS ModuloColAColB」を削除すると、すべて正常に動作します。

データベースのバージョン: SQL Server 2005 Enterprise Edition。

最近、私は NHibernate でページング機能を実装するのに忙しく、単純なエンティティでは問題なく動作しましたが、要求されたページを取得するために複数の結合が必要なエンティティではパフォーマンスの問題に遭遇しました。それに加えて、すべてのねじれたエイリアスと結合を使用せずにクエリを慣例に従って実行できれば、実装ははるかに簡単になります。

そこで、両方の問題 (または少なくともパフォーマンスの問題) を解決できる、いわゆるインデックス付きビューまたはマテリアライズド ビューを考えましたが、NHibernate でそれを行う方法に関するガイドや情報は見つかりませんでしたか? 一部のエンティティではデータが頻繁に更新/挿入されるため、問題はより複雑です。したがって、パフォーマンスの問題になる可能性のある積極的な更新が必要になる可能性があります。

何かアドバイス？

ありがとう