環境Aで非常に高速に実行されるように見えるSQLがありますが、環境Bではまったく同じクエリの実行が非常に遅くなります。
環境は同じであると想定されているので、クエリが同じように実行されない理由を確認するために何をすべきか、および/またはどこを調べればよいですか?
SQL Serverの内部と外部の両方に多くの要因があり、それらがまったく同じように構成されている場合でも、同じクエリが異なる環境間で異なる動作をする原因となる可能性があります。
サーバー
インスタンス
データベース
このすべてを念頭に置いて、多くの場合、さまざまな環境間でデータベースのすべての側面を完全にコピーすることは単純に不可能であることは当然のことです。テストを行うと、各環境でのクエリの実行方法についてある程度の確実性が得られますが、環境間に差異がある場合でも、当然のことです。新しいクエリを開発する場合、本番環境に移行するため、追加のチューニングが必要になることがよくあります。
通常、1つの環境で低速なクエリを調整しても、生成された実行プランに回帰が発生することはないので、全体的な改善のためにインデックス、統計、またはクエリ自体を調整する機会です。
最後の注記:下位の環境はサイズが小さく、多くの場合、実稼働環境または実稼働前環境と同じパフォーマンスを期待できません。
その他のリソース:
他の答えは良いですが、環境Bのデータ量と他のクエリとの競合を考慮する必要があることを付け加えます。
一部のSQLクエリは分離してパフォーマンスの問題を示しません(たとえば、テーブル内の1000行、他のクエリは実行されていません)が、テーブル内の10,000,000行でホラーショー(たとえば、パラメータースニッフィングの問題)、および/または他のクエリが書き込み、更新する可能性がありますまたは関連するテーブルをロックします。
最初にハードウェア/環境/構成が一致することを確認することに関する他の回答にも同意しますが、明らかなことが何もない場合は、クエリ実行プランの確認、SQLプロファイラーの実行などを開始します。
つまり、データベース自体が他と比較して遅いのか、その環境が遅いのかを特定する必要があります。最も簡単なことを最初に除外します。
これは何度か私に起こりました。それが環境であることが判明するたびに、別の誰かが1つのサーバー上のIOPSのdbを打ちのめして飢えさせていました。
遅いサーバーでtop(1)を実行し、CPUで大量の待機状態が発生しているかどうか、または仮想環境にいる場合はCPUがスチールしているかどうかを確認します。
これにより、実行計画でインデックススキャンの代わりに全テーブルスキャンが実行される原因となる欠落したインデックスを指摘することもできます(ただし、クエリロギングが遅い場合は簡単に見つけることができます)。これは、D状態のprocとしてpsにも表示されます。
それを除外したら、ハードウェアをより深く掘り下げる時が来ました。すべてのCPUに分散されている作業であり、ネットワークポートが100Mbに再ネゴシエートされています。両方のマシンでvmstatまたはiostatを実行し、違いを比較します。
データセットが同一の場合、同じクエリが両方で同じ実行プランを生成しますか?テーブルには同じ数の行が含まれていますか?インデックス定義は同じですか?テーブルに同様のレベルの断片化がありますか?アクティブな接続の数は同じですか?