web-dev-qa-db-ja.com

本番環境でのクエリが遅い、実行プランが悪い、またはインデックスが悪い?

インデックスを削除して再作成することで、本番パフォーマンスの問題を修正しました。インデックスを削除すると、それを使用した実行プランも削除されたと思います。

不正な実行計画を支持する引数:

  • インデックスを削除する前に、指定されたテーブルの統計の最終更新日を調べたところ、それらは最新でした。
  • 私のDBAが準備しました Hallengrenのインデックスおよび統計メンテナンスソリューション
  • 遅いクエリは、日付パラメータを使用してsp_executesqlから実行されたselectステートメントでした。 sp_executesqlなしで同じselectステートメントを実行すると高速でしたが、同じ実行プランを使用しませんでした。

不正な実行計画に対する引数:

  • インデックスを削除する前に、私たちは本気で禁止されたdbcc freeproccacheを実行して悪い計画をすべてクリアしましたが、これによってパフォーマンスの問題が修正または変更されることはありませんでした。

注:

  • 遅いクエリは、日付でインデックス付けされたテーブルを使用しています。ただし、各日付のレコード数には大きな違いがあります。つまり、特定の日付は数レコードから10万を超える範囲であり、かなりランダムです。

  • データベースは互換性レベル140(SQL Server 2017)で実行されています

問題の原因は、悪い計画または古いインデックスでしたか?
それが悪い計画である場合、なぜdbcc freeproccacheがそれを取り除くのに機能しなかったのですか?

問題が解決する前の計画

問題が解決された後の計画

編集:

私の知る限り、これは悪い計画のように見えましたが、どういうわけかdbcc freeproccacheは機能しませんでした。だから、私は暗闇の中で、全体の状況について混乱しています。

1
AXMIM

なぜ両方ではない?不正な統計を含む古いインデックスは、不正な計画を生成させる可能性があります。

2
Deerup

インデックスおよびメンテナンスソリューションのUpdateStatistics部分は、デフォルトでNULLに設定されています。

0
Ross