SQL Serverの凝集体

Question

我々は、製品の属性を含む17Mil行を持つテーブルを持っているが、のは、彼らがしているとしましょう：

brandID、sizeID、colorID、価格は、

をshapeIDそして、我々はを照会する必要がありますブランドとサイズ別に集計します。現在、このようなデータを照会してフィルタリングしています。

select brandID, sizeID, count(*) 
from table where colorID in (1,2,3) and price=10 and shapeID=17 
--"additional complex where clause here" 
group by brandID, sizeID 
order by brandID, sizeID 

このデータを報告します。問題は、返される実際のデータがほんの数百行にもかかわらず、このクエリを実行するのに10秒ほどかかります（これは非常に簡単な例です）。

私はこのテーブルのインデックス作成能力に達していると思いますので、インデックスの量はほとんどないと思います。

OLAPやその他の分析サービスについてはほとんど分かりませんが、上記のようなクエリ（または同様の返された同等のデータ）を実行できるように、このテーブルを事前フィルタリングまたは事前集計できるSQL Serverについては何がありますか？ または非常に大きなテーブルで任意のwhere句を処理する最善の方法は何ですか？

Answer 1

テーブル構造、物理環境、および（非）クラスター化インデックスなどの詳細がないと、ボトルネックを探す最初の場所は、クエリの「実行計画の表示」、つまりデータベースエンジンチューニングアドバイザーとSQLプロファイラーです。お役に立てれば。

Answer 2

私はこれがオラプルキューブにとって最適な候補だと思います。私は100億の行を持つ事実のデータを持っています。上記のような種類のクエリを実行していて、クエリは数分で戻ってきました。私はこれをOLAPキューブに移しました。そして、クエリはほぼ瞬間的になりました。 olapの学習曲線は少しあります。私はちょうどそれの周りにあなたの頭を得るためにいくつかの単純なキューブの建物についてのチュートリアルを見つけることを強くお勧めします。 DBAの同僚はキューブについて何年も話していましたが、決してそれを得ることはありませんでした。今私はなぜそれがなくてもずっと長く行ったのか分からない。

OLAPに加えて、インデックス付きのビューを調べることもできますが、いくつかの方法でデータをスライスすると実現できない場合があります。

Answer 3

はとにかくあなたのインデックスとスキーマ

に依存し、このクエリのためのあなたのインデックスはしかし

CREATE INDEX IX_foo ON table (shapeID, price, colorID) INCLUDE (brandID, sizeID) 
CREATE INDEX IX_foo ON table (shapeID, price, colorID, brandID, sizeID) 

の一つである必要があり、あなたは良い答えに対して軽減「句ここに追加の複雑な」を追加

私の思考：これが減少するため句が重要である

• ザ・
  • colorIDで（1,2、：行が
  • ORDER BYが
  • 集計/カバー

  エクストラ物事キーのルックアップを除去するためのクエリよりも重要であるがカウント3）はORであるため不正ですOR

• 暗黙的な変換を避けるために、パラメータデータ型が列データ型に一致するようにします。 shapeID、Price、colorIDをちょっと調べて、何が最善かを見極めることができます（またはいくつかのインデックスを作成し、どちらを使用するかを確認してください）
• SQLボトルネックがありますか？

Answer 4

SQL 2008を使用していて、頻繁に使用される特定のフィルタリングを使用している場合は、フィルタリングされたインデックスを使用することを検討してください（INCLUDEインデックスと併用することをお勧めします）。

5つのsizeID値しかないとします。現在のインデックスを複数のフィルタリングされたインデックスに分割することができます（例：「WHERE sizeID = 1」）。

フィルタリングをINCLUDEと組み合わせて使用​​すると、クエリがより速く返される可能性があります。

参考：Exploring SQL Server 2008’s Filtered Indexes