2

30〜40列の30GBのテーブルがあります。このテーブルを使用してレポートを作成すると、パフォーマンスの問題が発生します。レポートには、このテーブルの4〜5列を使用します。そのため、レポート用の2番目のテーブルを作成します。ただし、トリガーを使用せずに元のテーブルを変更した場合は、2番目のテーブルを更新する必要があります。

私のクエリが何であれ、クエリが実行されると、SQLはすべての30GBをキャッシュしようとします。キャッシュが完全にロードされると、SQLはディスクの使用を開始します。実はこれを避けたい

これどうやってするの？事前にssisthanksを使用してこれを行う方法はありますか

4

4 に答える 4

3 
CREATE VIEW myView
AS
SELECT
  column1,
  column3,
  column4 * column7
FROM
  yourTable

ビューは、事実上、マクロのように、単なる保存されたクエリです。次に、そのビューから、通常のテーブルであるかのように選択できます。

マテリアル化されたビューを使用しない限り、これは実際にはテーブルではなく、単なるクエリです。したがって、何も高速化されませんが、コードをカプセル化し、さまざまなユーザー/ログインが読み取ることができるデータの制御を支援します。

于 2012-06-22T11:57:33.543 に答える
0

Demsはビューで答えるのが理想的ですが、本当に新しいテーブルを探している場合は、それを作成して、トリガーで自動的に更新してください。

プライマリテーブルに配置されたトリガーは、プライマリテーブルに対するすべての挿入、更新、および削除アクションに追加できます。アクションが発生すると、トリガーが起動し、新しいセカンダリテーブルの更新などの追加機能を実行するために使用できます。挿入されたテーブルと削除されたテーブルからプルします（MSDN）

トリガーに関する多くの素晴らしい既存の記事があります： 記事1、記事2、Google検索

于 2012-06-22T13:02:22.497 に答える
0

考えているとおりに2番目のテーブルを作成し、トリガーを使用して、テーブル1が更新されるたびにテーブル2を更新できます。

ただし、トリガーには独自のパフォーマンスの問題があります。挿入と更新の速度が低下します。クエリのパフォーマンスを向上させるために、より従来型の代替手段を探すことをお勧めします。これは、SSISについて言及したのでSQLServerのように聞こえます。

30列のうち4〜5列しかないので、クエリをカバーするインデックスを追加してみましたか？WHERE句にさらに列があるかどうかはわかりませんが、最初に試してみてください。カバーインデックスは、クエリがテーブルに触れる必要がないため、実際にはあなたが説明していることを正確に実行します。もちろん、これはスペースと挿入/更新のパフォーマンスの点で少しコストがかかります。常にトレードオフがあります。

その上、30GBのテーブルから特定のレポートの行の大部分を引き出す必要があるとは信じられません。レポートに含めるにはデータが多すぎるだけです。フィルタリングされたインデックスは、要求される可能性が最も高い行にのみインデックスを付けることで、クエリのパフォーマンスをさらに向上させることができます。過去の暦月の結果を一覧表示するレポートがある場合は、WHERE report_date > '5/1/2012'たとえば、行のみにインデックスを付ける条件を追加できます。

于 2012-06-22T13:09:27.823 に答える
0

SQL Serverを使用している場合、必要なのはインデックス付きビューです。必要な列を使用してビューを作成し、それらにインデックスを配置します。

インデックス付きビューは、データをビューに格納します。基になるテーブルでビューを最新の状態に保つ必要があり、テーブルを読み取るためのI/Oを減らす必要があります。注：これは、4〜5列がテーブル全体よりもはるかに狭いことを前提としています。

于 2012-06-22T13:24:56.710 に答える