SQLクエリ最適化のギアをいじり始めるのは簡単です。 SQL Server Management Studio（SSMS）を開き、待機時間を監視し、実行プランを確認し、オブジェクト情報を収集して、微調整されたマシンを実行するまでSQLの最適化を開始します。
十分に上手くいけば、すぐに勝利を収め、定期的に予定されている混乱に戻ります。しかし、間違ったことを調整したり、正しいことを間違った方向に調整したりすると、水曜日になります。
SQLクエリの最適化？何があなたにそれが必要だと思いますか？
ほとんどの場合、トラブルチケットやユーザーからの苦情が急増しています。 「なぜシステムがこんなに遅いのですか？」あなたのユーザーは不平を言います。 「今週はいつものレポートを実行するのに永遠に時間がかかります。」
もちろん、それはかなり漠然とした説明です。 「CurrentOrderQuery5.sqlの62行目に暗黙の変換があるため、処理が遅くなります。列はvarcharであり、整数を渡しています。」ただし、ユーザーがそのレベルの詳細を確認できる可能性は低いです。
少なくともトラブルチケットと電話は、アクティブなメトリックを作成します：見つけやすく、測定しやすいです。彼らがロールインし始めたら、SQLチューニングの時間だと合理的に確信できます。
しかし、他にも、必要性を明確にしない受動的な指標があります。売上高の落ち込みなど、さまざまな要因が原因である可能性があります。あなたのオンラインストアでの痛々しいほど遅いクエリがあなたの顧客に彼らのショッピングカートを放棄させているからですか？景気が悪いからですか？
または、SQLServerのパフォーマンスが低下している可能性があります。記述が不十分なクエリが論理的な読み取りを屋根から送信しているためですか？サーバーのメモリやストレージなどの物理リソースが不足しているためですか？
どちらのシナリオでも、SQLクエリの最適化は最初のオプションには役立ちますが、2番目のオプションには役立ちません。
間違った問題に正しい解決策を適用するのはなぜですか？
最適化の道を進む前に、チューニングが適切な問題に対する適切な解決策であることを確認してください。
SQLの調整は技術的なプロセスですが、すべての技術的なステップには、ビジネス上の意味でのルーツがあります。実行時間を数ミリ秒短縮したり、論理読み取りの数を5％削減したりするために何日も費やすことができますが、その削減は時間の価値がありますか？ユーザーの要件を満たすことが重要であることは事実ですが、あらゆる努力が最終的に収穫逓減の段階に達します。
これらのSQLクエリのパフォーマンスの問題とその周辺のビジネスコンテキストを検討してください。
- 許容できるパフォーマンス —クエリの実行には10分かかり、ユーザーはクエリを1分で実行したいと考えています。これは、合理的な格差と最適化の達成可能な目標のようです。ただし、クエリに一晩かかり、ユーザーが1分で実行する必要があると考えている場合は、チューニングの問題以上の可能性があります。一つには、クエリが実際に実行している作業の量についてユーザーを教育する必要があるかもしれません。もう1つは、データベースの設計方法やクライアントアプリケーションの作成方法に問題がある可能性があります。
- ユーティリティ —製造会社の財務データベースの管理を担当しているとします。月末に、ユーザーはパフォーマンスの低下について不満を漏らします。問題は、経理によって実行される一連の月末レポートにまでさかのぼります。これらのレポートは、それぞれ数時間かかり、誰も調べていないファイリングキャビネットに直接入ります。調整する代わりに、ビジネスマネージャーに問題を説明し、レポートを削除する許可を取得します。
- タイムシフト —または、これらの同じレポートがガバナンスにとって重要であるが、ビジネスにとって緊急ではないとします。週に1回、または月に1回実行する場合は、データセットを事前にキャッシュし、結果をファイルに送信することで、オフピーク時間にスケジュールできます。これにより、他のビジネスユーザーのボトルネックが解消され、経理ユーザーはレポートを待つ必要がなくなります。
最適化の決定にビジネスコンテキストを考慮に入れると、優先順位を設定して時間を稼ぐことができます。
SQLクエリを最適化するときは、SQLダイアグラムを試してください
SSMSとSQLServerに組み込まれているツールは、効果的なSQLクエリの最適化に必要なもののほとんどを提供します。電子書籍「SQLクエリ最適化の基本ガイド」：で説明されているように、ツールを次の手順に沿った系統的なアプローチと組み合わせます。
- 待機時間を監視する
- 実行計画を確認する
- オブジェクト情報を収集する
- ドライビングテーブルを探す
- パフォーマンス阻害剤を特定する
ステップ4の目標は、返されるデータが最も少ないテーブルを使用してクエリを実行することです。結合と述語を調べ、クエリの後半ではなく早い段階でフィルタリングすると、論理読み取りの数が減ります。これは、SQLクエリの最適化における大きな一歩です。
SQLダイアグラムは、テーブル内のデータ量をマッピングし、どのフィルターが最も少ないレコードを返すかを見つけるためのグラフィカルな手法です。まず、詳細情報が含まれているテーブルと、マスターテーブルまたはルックアップテーブルであるテーブルを決定します。大学の登録データベースに対するこのクエリの簡単な例を考えてみましょう。
詳細表は登録です。学生とクラスの2つのルックアップテーブルがあります。これらのテーブルを図解するには、次のように、詳細テーブル（上部）を矢印（またはリンク）でルックアップテーブルに接続する逆さまのツリーを描画します。
次に、結合基準に必要なレコードの相対数（つまり、詳細テーブルとルックアップテーブルの間に関連する行の平均比率）を計算します。矢印の両端に数字を書いてください。この例では、すべての学生の登録テーブルに約5つのレコードがあり、すべてのクラスの登録に約30のレコードがあります。つまり、1人の生徒または1つのクラスの結果を取得するために、150（5×30）を超えるレコードを結合する必要はありません。
この演習は、結合列がインデックスに登録されていない場合、またはそれらがインデックスに登録されているかどうかわからない場合に役立ちます。
次に、フィルタリング述語を調べて、クエリを実行するテーブルを見つけます。このクエリには2つのフィルターがありました。1つはキャンセルされた登録=「N」で、もう1つは2つの日付の間のsignup_dateです。フィルタの選択性を確認するには、登録時に次のクエリを実行します。
キャンセルされた登録からcount（1）を選択=‘N’
AND r.signup_date BETWEEN：beg_date AND：beg_date +1
登録中の合計79,800レコードのうち4,344レコードを返します。つまり、レコードの5.43パーセントがそのフィルターで読み取られます。
もう1つのフィルターはクラスにあります：
name =‘ENGLISH 101’
のクラスからcount（1）を選択します1,000、つまり0.2パーセントのうち2つのレコードを返します。これは、はるかに選択的なフィルターを表します。したがって、クラスは駆動テーブルであり、SQLチューニングを最初に集中させるためのテーブルです。
ユーザーの声
SQLチューニングが必要であると確信している場合は、「SQLクエリ最適化の基本ガイド」でさらに洞察を得ることができます。上記のものを含む、コピーアンドペーストクエリとケーススタディを使用した5つのパフォーマンスチューニングのヒントについて説明します。
おそらく、最も重要なSQLクエリ最適化ツールはユーザーの声であることがわかるでしょう。なんで？その音声は、最適化を開始するタイミングを通知し、十分に最適化したタイミングを通知するためです。必要なときにギアをいじり始め、まだ先にいる間に停止することができます。