私を怒らせている問題の解決策を見つけようとしています...
QA サーバーでは非常に高速に実行されるクエリがありますが、本番環境では非常に低速です。実行計画が異なることに気付きました...再コンパイル、実行計画のキャッシュの消去、統計の更新、照合の種類の確認を試みました...しかし、何が起こっているのかまだわかりません...
クエリが実行されているデータベースはまったく同じであり、SQL Server も同じ構成です。
新しいアイデアは大歓迎です。
ありがとう、A.
QA サーバーが SP3 を実行しており、本番環境では SP2 であることに気付きました。これは、この問題に何らかの影響を与える可能性がありますか?
存在するデータの量が原因である可能性があると思います。ある時、QA サーバーではクエリが文字どおり飛んでいたのに、実稼働環境では信じられないほど遅いということがありました。しばらく頭を悩ませた後、QA サーバーには 15,000 行あり、本番環境には 150 万行あることがわかりました。
HTH
運用サーバーのデータベース サイズが大きい可能性はありますか? 含まれるデータの統計に基づいているため、計画は異なる場合があります。
実行計画が同じで、一方が遅い場合、データベースの負荷、ハードウェア、ロック/ブロッキングなどが原因です。
ただし、実行計画が異なる場合、2 つのデータベース間で何かが異なります。統計は両方で最新であるか、まったく同じスキーマ、同じインデックス、同様の行数、同じ分布の PK とインデックス値などを持っていますか?
私は最近これに出くわし、ここに私が見つけたものがあります。
基本的に互いのコピーである 2 つのデータベースがありました。あるバージョンでは TVF の実行に 1 秒かかっていましたが、別のバージョンでは実行に 15 分かかりました。
基礎となる SQL コードの実行計画は非常に異なっていました。TVF が依存していたいくつかのインデックスを再構築することで修正できました。実行計画は同じではありませんが、大きく変わりました。また、実行時間は約 1 秒に短縮されています。
現在、両方のバージョンに高度に断片化されたインデックスがありました。私の推測では、過去の統計情報または実行計画の情報により、高速バージョンは最適な実行計画を見つけ続けることができたということです。
要約すると、インデックスの構造が同じであったり、断片化率が似ていたりしても、インデックスの断片化を確認するようにしてください。
本番環境での並列クエリ実行を無効にします:)