0

このクエリを使用して、ジョブの検索データを取得します（以下を参照してください。簡単にするために省略します）。約100万件のレコードを扱っています。

Select ID
from
(
    Select ID,createDate
    ,SearchKeyMatchRank
    ,Row_Number() over(Order By createDate) As rowNumber
    from Jobs J
    OUTER APPLY
    (
        Select SearchKeyMatchRank=
        CASE WHEN @searchKey='""' THEN 0
        ELSE
        (Select IsNull([RANK],0) from FREETEXTTABLE(Jobs,title,@searchKey) Where [Key]=J.ID)*4
        +(Select IsNull([RANK],0) from FREETEXTTABLE(Jobs,description,@searchKey) Where [Key]=J.ID)*4
        +(
        select SUM(ISNULL(JS2.[Rank],0))
        from FREETEXTTABLE(JobSkills,skill,@searchKey) JS2
        Where JS2.[Key] in (Select ID from JobSkills Where jobId=J.Id)
        )*2
        END
    ) SMR
    Where
    SearchKeyMatchRank>0 --simplified here
) T2
where
rowNumber>=CASE WHEN @startIndex>0 AND @endIndex>0 THEN @startIndex ELSE rowNumber END
AND rowNumber<=CASE WHEN @startIndex>0 AND @endIndex>0 THEN @endIndex ELSE rowNumber END

ノート：

jobIdをREETEXTTABLEに渡して加重ランクを見つける必要があるため、通常の結合を使用できません。

問題：

その非常に遅い。

どうやら問題は計算列を比較することです。

SearchKeyMatchRank>0

Where SearchKeyMatchRank> 0を離陸すると、1秒もかかりません。

誰かがこれをどのように改善できるか考えましたか？

4

2 に答える 2

0

列が非決定論的関数を使用している場合、私たちが取ったアプローチは、テーブルに通常の列を定義し、挿入/更新トリガーを追加して値を更新することです。このように、従属フィールドが変更されたり、新しいレコードが追加されたりすると、わずかなヒットが発生しますが、列は標準 SQL 列であるため、クエリのパフォーマンスには影響しません。また、インデックスも簡単に作成できます。

于 2013-09-02T23:53:47.183 に答える
0

これを改善する方法を知っている人はいますか?

列を計算列から「通常の」列に変更します。テスト環境で試して、パフォーマンスの向上が同じかどうかを確認してください。

于 2011-09-02T21:13:03.780 に答える