SQL Server 2008 R2 を使用しています。
プロセスは実際には次のようになります。
まず、約200 万件のレコードがリモート サーバーから取得され、
その後、ローカルで結合が行われ、
最終結果は何千ものレコードになります。
時間のコストは、1 分未満から 30 分までさまざまです。
そして、30分の遅延を経験した後、次の時間コストはすべて約3分だけのようです.
同じデータ、同じSPです。
この劇的な違いの原因は何ですか?
SP を削除し、SQL サーバー サービスを再起動して、SP を再作成します。実行にかかった時間はわずか 50 秒でした。
どうしたの？
あなたが説明した動作は極端に思えますが、(クライアントを除外すると) 3 つの論理的な場所があります。
1 つ目は、データベース サーバーでのクエリの実行です。クエリ アナライザー ツールを使用して、インデックスが使用されているかどうかを確認する価値があります。データベース クエリのパフォーマンスが変動する最も一般的な理由は、クエリが (正しい) インデックスを使用していないため、クエリ キャッシュの影響が発生することです。大きな部分。SQL Server は大量のデータをキャッシュし、proc の最初の実行でそのキャッシュにデータを取り込みます。2 回目の実行は、キャッシュにヒットするため高速です。しばらくすると、キャッシュが古くなり、proc の実行が再び遅くなります。
2 番目の可能性は、データベース サーバーが不安定であるということです。実行することになっているすべての作業を実行するのに十分なほど強力ではない可能性があります。その場合、幸運なことに、すべてのサーバー リソースを独り占めできます。次に、他の誰かがクエリを実行していて、あなたのクエリが遅くなります。これは、このクエリだけでなく、すべてのクエリを遅くするため、そうは思えません。
3 番目の可能性はネットワークの奇妙さです。Phil が言うように、「何千ものレコード」はそれほど恐ろしいものではありませんが、それらが大きく、ネットワークが子猫の写真で飽和している場合、影響があるかもしれません。繰り返しますが、それは一般的なネットワークの遅さとして現れ、30 分の遅延を説明する可能性は低いです...
第四に、同時に何かが起こっていますか？
第 5 に、SP は動的に生成された SQL ステートメントを使用していますか? これにより、SP がプリコンパイルされなくなります。可能であれば、そのようなステートメントを子 SP に分けてください。