3

興味深い問題があり、誰かが光を当てるのを手伝ってくれることを望んでいました. 大まかな問題は次のとおりです。

次のクエリはすばやく (1 秒) 実行されます。

SELECT SA.*
FROM cg.SEARCHSERVER_ACTYS AS SA
JOIN CONTAINSTABLE(CG.SEARCHSERVER_ACTYS, NOTE, 'reports') AS T1 ON T1.[Key]=SA.UNIQUE_ID

ただし、クエリにフィルターを追加すると、返されるまでに約 2 分かかります。

SELECT SA.*
FROM cg.SEARCHSERVER_ACTYS AS SA
JOIN CONTAINSTABLE(CG.SEARCHSERVER_ACTYS, NOTE, 'reports') AS T1 ON T1.[Key]=SA.UNIQUE_ID
WHERE SA.CHG_DATE>'19 Feb 2010'

2 つのクエリの実行計画を見ると、2 番目のケースでは、実際の行数と推定行数に大きな違いがある場所が 2 つあります。これらは次のとおりです。

1) FulltextMatch テーブル値関数の場合、見積もりは約 22,000 行で、実際の行は 2,900 万行 (その後、結合前に 1,670 行にフィルター処理されます) および 2) フルテキスト インデックスのインデックス シークの場合、見積もりは 1 行で、実際は 13,000 行です

見積もりの​​結果、オプティマイザーはネストされたループ結合を使用することを選択しているため (少数の行を想定しているため)、計画は非効率的です。

この問題を回避するには、(a) クエリをパラメータ化して OPTION (OPTIMIZE FOR UNKNOWN) をクエリに追加するか、(b) HASH JOIN の使用を強制します。どちらの場合も、クエリは 1 秒未満で返され、見積もりは妥当に見えます。

私の質問は、「パフォーマンスの低いケースで使用されている推定値が非常に不正確である理由と、それらを改善するために何ができるか」ということです。

ここで使用されているインデックス付きビューのインデックスに関する統計は最新です。

どんな助けでも大歓迎です。

4

2 に答える 2

1

ここでの問題は、SQL Server のバージョンにあることが判明しました。この問題は SQL Server 2008 (サービス パックなし) で発生し、SQL Server 2008 SP1 にアップグレード (および CU5 を追加) することで解決されました。CU5 をインストールせずにテストを行っていないため、修正プログラムが SP1 に付属しているのか CU5 に付属しているのかを判断することはできません。何はともあれ、問題は解決しました。士気？サーバーを最新の状態に保ちます。

于 2010-06-02T18:58:34.710 に答える
0

おそらく、問題の列にいくつかの統計を追加できます。これにより、SQL Server が行数とその内容の両方についてより適切な見積もりを行うのに役立ちます。

現在関与している統計または索引は?

于 2010-04-16T19:41:17.903 に答える