10

これが幅広い質問であることはわかっていますが、パフォーマンスの低いいくつかのパフォーマンスを継承しており、それらをひどく最適化する必要があります。最適化に関連する最も一般的な手順は何だろうと思っていました。では、同じ状況に直面したとき、皆さんはどのような行動をとりますか?

関連する質問:
SQL クエリを最適化するために適用できる一般的な手法は何ですか?

4

7 に答える 7

15
  1. クエリ アナライザーで実行プランを確認する
  2. 最も費用がかかるステップを確認する
  3. ステップを最適化!
  4. ステップ 1 に戻ります [Thx to Vinko ]
于 2008-09-14T00:24:56.030 に答える
7

SQL Server では、クエリ アナライザーまたは Management Studio でクエリ プランを確認できます。これにより、ステートメントの各バッチに費やされたおおよその割合がわかります。次のものを探す必要があります。

  • テーブル スキャン。これは、インデックスが完全に欠落していることを意味します
  • インデックス スキャン。クエリが正しいインデックスを使用していない可能性があります
  • クエリの各ステップ間の矢印の太さは、そのステップで生成される行数を示します。非常に太い矢印は、多くの行を処理していることを意味し、いくつかの結合を最適化する必要があることを示している可能性があります。

その他の一般的なヒント:

  • 複数の if-else ステートメントなど、大量の条件付きステートメントがあると、SQL Server がクエリ プランを絶えず再構築する可能性があります。これは、Profiler を使用して確認できます。
  • update ステートメントが select ステートメントをブロックするなど、異なるクエリが互いにブロックしていないことを確認します。これは、SQL Server の select ステートメントで (nolock) ヒントを指定することで回避できます。
  • 他の人が言及したように、Management Studio でパフォーマンス チューニング ウィザードを試してください。

最後に、(Visual Studio 2008 Test Edition を使用して) 一連の負荷テストを作成することを強くお勧めします。これは、大量の要求を処理するときのアプリケーションの動作をシミュレートするために使用できます。一部の SQL パフォーマンスのボトルネックは、このような状況でのみ顕在化します。それらを再現できると、修正がはるかに簡単になります。

于 2008-09-14T02:43:37.553 に答える
3

インデックスは、開始するのに適した場所かもしれません...

簡単に達成できる問題は、SQL Serverインデックスチューニング ウィザードで解決できます。

于 2008-09-14T00:24:33.223 に答える
2

他のデータベースについてはわかりませんが、SQL Server の場合は実行プランをお勧めします。非常に明確に (ただし、400 インチのモニターを使用していない限り、垂直および水平スクロールが多いにもかかわらず!) クエリのどのステップが時間を浪費しているかを示しています。

1 つのステップに 80% もの時間がかかる場合は、インデックスを追加して、インデックスを微調整した後、実行計画を再実行して、次の最大のステップを見つけます。

いくつかの微調整の後、他のステップより際立っているステップが実際にないことがわかる場合があります。つまり、それらはすべてそれぞれ 1 ~ 2% です。その場合、クエリに含まれるデータの量を削減できる方法があるかどうかを確認する必要があるかもしれません。これらの 400 万件のクローズされた販売注文を「アクティブな販売注文」クエリに含める必要がありますか? ? いいえ、STATUS='C' ... またはそのようなものをすべて除外します。

実行プランから得られるもう 1 つの改善点は、ブックマーク ルックアップです。基本的には、インデックス内で一致するものを見つけますが、SQL Server は必要なレコードを見つけるためにテーブルをすばやくトロールする必要があります。この操作は、最初にテーブルをスキャンするよりも時間がかかる場合があります。その場合、そのインデックスは本当に必要ですか?

インデックスの場合、特に SQL Server 2005 の場合は INCLUDE 句を検討する必要があります。これにより、基本的に、実際にはインデックスに含まれていなくてもインデックスに列を含めることができるため、クエリに必要なすべてのデータがインデックスまたはが含まれている列である場合、SQL Server はテーブルを参照する必要さえなく、パフォーマンスが大幅に向上します。

于 2008-09-14T04:07:29.100 に答える
2

クエリのパフォーマンスを最適化するために確認できることがいくつかあります。

  1. 最小限のデータしかないことを確認してください。必要な列のみを選択してください。フィールド サイズを最小限に抑えます。

  2. 結合を減らすためにデータベースを非正規化することを検討してください

  3. ループ (つまり、カーソルのフェッチ) を避け、セット操作に固執します。

  4. ストアド プロシージャとしてクエリを実装します。これはプリコンパイルされており、より高速に実行されます。

  5. 正しいインデックスが設定されていることを確認してください。データベースが主に検索に使用されている場合は、インデックスを増やすことを検討してください。

  6. 実行計画を使用して、処理がどのように行われるかを確認します。回避したいのは、コストがかかるテーブル スキャンです。

  7. 自動統計がオンに設定されていることを確認します。SQL は、最適な実行を決定するためにこれを必要とします。詳細については、Mike Gunderloy のすばらしい投稿を参照してください。SQL Server 2005 における統計の基礎

  8. インデックスが断片化されていないことを確認するSQL Server インデックスの断片化を減らす

  9. テーブルが断片化されていないことを確認してください。SQL Server 2000 および 2005 でテーブルの断片化を検出する方法

于 2008-09-14T15:37:02.297 に答える
1

実行計画は素晴らしい出発点であり、クエリのどの部分に取り組む必要があるかを理解するのに役立ちます。

場所を把握したら、次はその方法と理由に取り組みます。実行しようとしているクエリのタイプを確認してください。ループは遅いため、絶対に避けてください。カーソルは遅いため、絶対に避けてください。可能な限り、セット ベースのクエリに固執します。

結合を使用している場合、使用する結合のタイプに関する SQL ヒントを与える方法があります。ただし、データとパラメータによっては、1 つのヒントでクエリが 1 回高速化されても、次回は 10 倍遅くなる可能性があることに注意してください。

最後に、データベースのインデックスが適切に作成されていることを確認してください。開始するのに適した場所は、where 句に含まれる任意のフィールドであり、おそらくインデックスが必要です。

于 2008-09-14T02:45:22.853 に答える
1

クエリを作成するテーブルのインデックスを確認します。where 句に参加する特定のフィールドにインデックスが必要になる場合があります。また、クエリの結合で使用されるフィールドも確認します (結合が存在する場合)。インデックスが既に存在する場合は、インデックスの種類を調べます。

これに失敗した場合 (ロック ヒントの使用にはマイナス面があるため) ロック ヒントを確認し、結合で使用するインデックスに明示的に名前を付けます。デッドロックされたトランザクションが大量に発生している場合は、NOLOCKS を使用する方がより明白です。

ただし、roman と Andy S が最初に言及したことを実行してください。

于 2008-09-14T00:38:06.453 に答える