SQLServerデータベースに1,000万以上のレコードを含む大きなテーブルがあります。この表には、米国の50州すべての特定のタイプのデータが含まれています。したがって、このテーブルから状態ごとに1つずつ、50のビューを作成すると、アプリケーションからクエリを作成するパフォーマンスが向上しますか？他の提案？
2542 次
6 に答える
8
いいえ。ビューは展開するマクロであるため、とにかく同じテーブルがプランに含まれることになります。
インデックスが付けられていない限り。50のインデックス付きビューはおそらくやり過ぎです。
5,000万行でパフォーマンスが遅い場合（実際にはそれほど多くはありません）、インデックス作成の問題です。
編集：
まず、加重欠落インデックスdmvクエリを使用して、コストを最大限に活用できる場所を確認します。
于 2010-09-14T18:23:16.117 に答える
2
通常の（インデックス付けされていない）ビューはパフォーマンスを向上させることはできません。物理的な構造がないため、SELECTクエリの「省略形」または「エイリアス」と考えることができます。
インデックス付きビューは別の獣ですが、今のところ必要ではないようです。
必要なのは、テーブルに適切なインデックスを作成し、場合によってはテーブルを再設計することです（たとえば、テーブルを複数のテーブルに分割します）。
より具体的なアドバイスが必要な場合は、ここにテーブル構造と一般的なクエリの例（最適化するクエリ）を投稿してください。
于 2010-09-14T18:23:40.517 に答える
0
あなたは正しい方向に進んでいます：
高速である必要がある読み取りを反映するようにデータにインデックスを付けることから始めます。次に、フィルタリングによって高速化されるため、ストアドプロシージャ（状態のパラメーターを使用）を介してデータにアクセスできるようにすることで、状態をフィルタリングする必要があると考えます。
于 2010-09-14T18:20:17.420 に答える
0
実行プランに適切なインデックスと使用法がある場合、大きな問題はメモリキャッシュの量とディスクの読み取り速度です。ビューを作成しても、それらは修正されません。同じディスク/キャッシュ上の同じデータであり、論理的に参照する方法が異なります。
于 2010-09-14T18:24:23.257 に答える
0
1つの簡単な提案：
use [YourDataBase]
select * from sys.dm_db_missing_index_details as ddmid
于 2010-09-14T18:25:56.940 に答える
0
これは非常に小さなデータベースであるため、インデックス作成にパフォーマンスの問題がある場合、データベースの設計が不適切であるか、パフォーマンスの低いクエリを設計している場合があります。SQL Serverは、正しく設計されていれば、汗をかくことなく何兆ものレコードを処理できます。
ビューを呼び出すビューを使用する場合、ビューBTWはパフォーマンスキラーになる可能性があります。
于 2010-09-14T20:30:32.623 に答える