0

取得したテーブルを含むSQLクエリがあります。

派生クエリは次のようになります。

SELECT 
   ObjectId, MIN(StatusHistoryId) AS FirstStatusHistoryId
FROM 
   dbo.StatusHistory
WHERE 
   ObjectType = 'SchemeTypeApplication' 
   AND (StatusId = 504 OR StatusId = 501) 
   AND IsDeleted = 0    
GROUP BY 
   ObjectId

これは、それ自体で完了するのに約2分かかり、30万行近くを引き戻します。クエリ全体（これを内部に含む）は、ほぼ同じです。派生テーブルがないと、1秒もかからないので、問題を引き起こしているのは派生クエリであることがわかります。

私の質問は、dereivedテーブルクエリの速度を改善する方法はありますか？たぶん、StatusHistoryテーブルにいくつかのインデックスを追加します（私はインデックス付けに少しごちゃごちゃしています...）？または、派生テーブルを使用する以外のアプローチはありますか？

任意の提案をいただければ幸いです。

ありがとう

4

3 に答える 3

1

上記の私のコメントを参照してください。フィールドにインデックスStatusIDがない場合は、フィールドにインデックスを導入することもできます。返されるレコードの数の順に、より制限の厳しい列をWHERE句に配置してみてください。

于 2012-02-01T15:58:59.837 に答える
1

JonHが指摘したように、インデックスを展開し、WHERE基準に基づいて期待される結果の最小粒度と見なされるものに基づいて主要な要素を設定します...文字列である「ObjectType」は、列挙可能であれば、より最適化される可能性がありますテキストよりも整数値ベース。粒度については。これは、レコードの最小量を返します...ステータスIDは、「SchemeTypeApplication」のオブジェクトタイプに対して（OR条件を介して）501と504を組み合わせたものです。501に50,000レコード、504に30,000レコードがあるが、「SchemeTypeApplication」に475,000レコードがある場合、最初にステータスIDにインデックスを設定します。そうでない場合は、その逆になります。 475,000のオブジェクトタイプの多くは501と504であり、おそらく50,000であり、これで完了です。はい、元のコメントは約300k行を返すことを示していますが、これはクエリが一般的に使用される方法に基づいた最適化インデックス手法の決定のサンプルにすぎません。だから、私は次のようなものにインデックスを付けます

（statusID、ObjectType、IsDeleted、ObjectID）

于 2012-02-01T16:17:42.067 に答える
0

Management Studio 2008（2008または2005データベースを使用）を使用している場合は、実行プランを調べて、作成する必要のある欠落しているインデックスが推奨されているかどうかを確認できます。

私の推測では、このクエリに対する推奨事項があります。

ここにいくつかのスクリーンショットがあります： http ：//weblogs.sqlteam.com/mladenp/archive/2008/12/29/SQL-Server-Management-Studio-2008-suggests-missing-indexes-with-actual.aspx

于 2012-02-01T17:54:48.573 に答える