クエリパフォーマンスチューニング

クエリ/ストアドプロシージャ/関数の作成が完了したら、パフォーマンスパラメータをすばやく取得する最も有益な方法は何ですか？クエリを実行し、実際の実行計画を表示しますか？もしそうなら、あなたが探しているものは何ですか？明らかにテーブル/インデックススキャンはビットヒットですが、他には何がありますか？

迅速な評価のために、実行計画をSSMSから取得してPlan Explorerに入力します。

• 予想外のものについては、最も高価な操作を確認してください。並べ替え、作業テーブル、不適切な結合演算子（たとえば、マージまたはハッシュが予想されるネストされたループ）。
• 計画の各段階で行数を確認します。これらは、予想される範囲内に広く含まれていますか？
• 推定された行と実際の行を見てください。実績が見積もりに近い場合、適切な計画を立てている可能性が高くなります。大きなバリエーションがある場合は、その理由を見つけてください（たとえば、欠落している統計や古い統計など）。
• パラメータスニッフィングの問題の可能性を評価します。カーディナリティが変化する可能性のある領域を探し、入力パラメーターの範囲に対してテストします。

無料で入手できる参考資料がたくさんあります。GrantFitchleyのSQL Server Execution Plansは良い出発点です。また、Joe Changのブログ投稿と実行計画コストに関する電子書籍が非常に役立つこともわかりました。

ほとんどの場合、クエリを実行し、実際のデータに対して実行する方法を見つけるだけです。問題がある場合は、実行計画を確認します。

実行計画に関しては、Brad McGeheeがこのテーマに関する興味深い記事を持っています。

その中で彼は言います：

実行計画に次のいずれかが表示された場合、それらを警告サインと見なし、潜在的なパフォーマンスの問題について調査する必要があります。それらはそれぞれ、パフォーマンスの観点からは理想的ではありません。

* Index or table scans: May indicate a need for better or additional indexes.

* Bookmark Lookups: Consider changing the current clustered index, consider using a covering index, limit the number of columns in the SELECT statement.

* Filter: Remove any functions in the WHERE clause, don’t include wiews[sic] in your Transact-SQL code, may need additional indexes.

* Sort: Does the data really need to be sorted? Can an index be used to avoid sorting? Can sorting be done at the client more efficiently? 

これらを回避できるとは限りませんが、回避できるほど、クエリのパフォーマンスは速くなります。

SET STATISTICS IO ON

一般に、「論理読み取りの数」はできるだけ少なくする必要があります。クエリを完了するために触れたページが少ないほど、（通常）速くなり、CPU、RAM、およびディスクIOへの影響が少なくなるため、計画は改善されます。

これは、インデックスの変更やSQLのリファクタリングが実際に役立つ場合に役立ちます。「ミリ秒の実行時間」を見ると、同じSQLおよびクエリプランでも変化します。特定のクエリプランで論理読み取りの一貫性が保たれます。

また、「物理読み取り」は非常に低くする必要があります（ゼロであり、後続の実行ではゼロのままです）。これで解決しない場合は、SQL Serverのメモリ使用量（ページの寿命など）を確認してください。