0

テーブル内に約 3 億 6,500 万行あり、データが 1 年経過すると、データをアーカイブする別のテーブルに移動されると、毎日 100 万行が追加されます。

DataCollectionID に PK クラスター化インデックスがあります。

もう 1 つのインデックスがあります。AssetID、DataPointID、および DatapointDate の Unique Nonclusted インデックスです。

テーブルに対して複数の選択クエリを非常に迅速に実行する必要があります...これが私の選択クエリです:

SELECT [DataPointID]
  ,[SourceTag]
  ,[DatapointDate]
  ,[DataPointValue]
FROM DataCollection
Where 
  DatapointDate >= '2012-09-07' AND 
  DatapointDate < '2012-09-08' AND
  DataPointID = 1100
ORDER BY DatapointDate

このクエリは 8,640 行を返す必要がありますが、実行には 00:00:08 (8 秒) かかります。トップ 10 を教えてくださいと言っても、8 秒かかります。誰かがこのプロセスをスピードアップするのを手伝ってくれますか?

4

3 に答える 3

3

このクエリを支援するためのより効果的なインデックスは、DataPointID、DataPointDate の順序であると思います。これにより、オプティマイザーは、最初のインデックス列で等値演算子を使用してフィールドをすばやく絞り込み、そのセット内の日付範囲を見つけることができます。

インデックスと同様のクエリの良い例がいくつかあります:

http://sqlserverpedia.com/wiki/Index_Selectivity_and_Column_Order

于 2012-09-11T16:17:37.187 に答える
0

次のような、より良いカバリング インデックスが必要です。

create index _idx ON DataCollection ( DataPointDate, DataPointId )
include ( SourceTag, DataPointValue )

通常、インデックスの前に最も選択的な (つまり、最もユニークな) 列が必要なため、これはデータに応じて dataPointDate または dataPointId になります。

于 2012-09-11T16:28:12.903 に答える
0

これが動的 SQL の場合は、それをストアド プロシージャに入れ、忘れずに を使用する必要がありますSET NOCOUNT ON。

それ以外の場合は、ハードウェアの問題のように思えます。この場合、メモリを増やすと役立つ場合があります。

于 2012-09-11T16:10:03.987 に答える