4

実稼働システムでは約 5 秒かかるクエリがありますが、ミラー システム (可能な限り実稼働と同じ) と開発システムでは 1 秒未満かかります。

クエリ プランを確認しましたが、それらが異なることがわかります。また、これらの計画から、一方が他方よりも時間がかかっている理由がわかります。データ、スキーマ、およびサーバーは類似しており、ストアド プロシージャは同一です。

結合を再配置してヒントを追加することで修正する方法はわかっていますが、現時点では、SProc (ペーパーワーク) を変更する必要がない方が簡単です。sp_recompile も試しました。

2 つのクエリ プランの違いの原因は何ですか?

システム: Win2k3 Enterprise 上の SQL 2005 SP2 Enterprise

更新: ご回答ありがとうございます。それは統計であることがわかりました。以下の概要を参照してください。

4

6 に答える 6

12

あなたの統計はおそらく古くなっています。データが同じである場合は、両方のサーバーで統計を再計算して再コンパイルします。その後、同一のクエリ プランが表示されます。

また、インデックスが同一であることを再確認してください。

于 2009-02-03T04:32:31.637 に答える
3

ミラーと本番の間のデータとデータ サイズは可能な限り同じですか? あるクエリが他のクエリよりも時間がかかる理由を知っている場合は? 詳細を投稿できますか?

このような場合、テーブルや統計のデータが原因で、実行計画が異なる場合があります。統計の自動更新がオンになっている場合でも、統計が古くなっている可能性があります (特に非常に大きなテーブルの場合)。オプティマイザーがテーブルをそれほど大きくないと推定し、テーブル スキャンなどを選択していることに気付く場合があります。

于 2009-02-03T04:36:37.290 に答える
0

解決策は、統計を再計算することでした。いつものように、そのすべてを実行するタスクをスケジュールしているのを見落としていましたが、何らかの理由で、管理者がこのサーバーに 1 つも配置しませんでした。

すべての投稿を要約するには:

  • セットアップが同じであることを確認します
    • インデックス
    • テーブルサイズ
    • データベースの復元
  • 実行計画のキャッシュ
    • クエリが SProc の外で同じように実行される場合、それは実行プランではありません
    • 異なる場合は sp_recompile
    • パラメータ盗聴
  • 統計の再計算
于 2009-02-03T05:25:58.033 に答える