6

私はすでにこのクエリを1時間以上待っていたので、おそらく何か間違ったことをしていると思います。このクエリを調整する効率的な方法はありますか？

select RespondentID, MIN(SessionID) as 'SID'
from BIG_Sessions (nolock)
where RespondentID in (
1418283,
1419863,
1421188,
1422101,
1431384,
1435526,
1437284,
1441394,
/* etc etc THOUSANDS */
1579244 )
    and EntryDate between
    '07-11-2011' and '07-31-2012'
GROUP BY RespondentID

私の日付範囲はかなり広いことは知っていますが、その部分を変更することはできません（日付は全体に広がっています）。

また、その理由MIN(SessionID)は、それ以外の場合は、回答者ごとに多くのSessionIDを取得し、1つで十分であるためです（ach2a23a-adhsdx123などの英数字IDでMINを取得し、最初のアルファベットを取得します）

ありがとう

4

2 に答える 2

6
  1. 数千の数字を一時的なテーブルに入れます。
  2. そのテーブルの数値フィールドにインデックスを付けます。
  3. BIG_SESSIONSのRespondentIDフィールドにインデックスを付けます
  4. 2つのテーブルを結合します

例えば：

select RespondentID, MIN(SessionID) as 'SID' 
from BIG_Sessions (nolock) 
    inner join RespondentsFilterTable 
        on BIG_SESSIONS.RespondentID = RespondentsFilterTable.RespondentID
where EntryDate between '07-11-2011' and '07-31-2012' 
GROUP BY BIG_Sessions.RespondentID

EntryDateとSessionIDにもインデックスを追加できますが、big_sessionsに頻繁に追加する場合は、他の場所では逆効果になる可能性があります。

一般に、推定された（または可能であれば実際の）実行プランを調べることで、クエリのパフォーマンスをどのように改善できるかについてのヒントを得ることができます。

于 2012-07-31T22:50:27.480 に答える
1

INステートメントの最小IDと最大IDが事前にわかっていて、テーブルにあるIDの数に応じてrespondedID > [smallest_known_id-1] AND respondedID < [largest_known_id+1]、INステートメントの前に前に追加すると問題を制限するのに役立ちます

于 2012-07-31T23:25:21.820 に答える