データベースを管理する人なら誰でもよく知っているように、SQLServerのパフォーマンスチューニングは最適なパフォーマンスを確保するための重要な機能です。パフォーマンスは、メモリ、構成、クエリの設計、リソースの使用量などのさまざまな要因に依存するため、パフォーマンスの低下の根本的な原因を特定することは簡単なことではありません。
パフォーマンスの問題が発生するのを待つのではなく、SQL Serverをプロアクティブに調整することで、SQLがクエリ結果を提供するための最速のルートを見つけられるようにすることで、SQLステートメントを可能な限り効率的に実行できるようになります。
パフォーマンスの低下に苦しんでいる場合、または問題が発生するのを待つだけではない場合、最適なパフォーマンスとより健全なシステムを実現するためにSQLServerのパフォーマンスチューニングに焦点を当てる3つの重要な領域を次に示します。
ヒント＃1：TempDBを最適化する
不適切に構成されたTempDBは、パフォーマンスの低下を確認する際の一般的な原因です。 TempDBが頻繁にいっぱいになる場合は、何を変更する必要があるかを見てみましょう。
まず、TempDBのサイズを確認します。大きさについての厳格なルールはありませんが、経験則として、TempDBを最大のデータベースの25％、または最大のインデックスと同じサイズに保つことをお勧めします。これにより、再構築中にTempDBを増やす必要がなくなります。
TempDBを使用すると、ドライブが高速であるほど優れています。 TempDBを低速のドライブまたはOSと同じドライブに配置すると、データベースのパフォーマンスの問題が必ず発生します。可能であれば、TempDBを専用のローカルSSDに保持します。それが不可能な場合、次善の策は、事前に割り当てられた十分なディスク容量を備えた専用のボリュームにそれを保持することです。
データとログファイルを別々に保ち、TempDB自動拡張に大きな固定値を設定することも重要です。そうしないと、TempDBがいっぱいになるたびに不要なオーバーヘッドが発生します。
TempDBデータファイルの数を制御することは、TempDBの最適化に貢献します。しかし、大きな問題は、TempDBデータファイルがいくつ必要かということです。理想的には、論理CPUごとに1つのTempDBデータファイルがありますが、合計で8つ以下です（一部の例外を除く）。たとえば、4つの論理CPUがある場合、4つのTempDBデータファイルが必要です。 12個の論理CPUがある場合、8個のTempDBデータファイルを持つことができます。
ヒント＃2：パフォーマンスのボトルネックを防ぐ
パフォーマンスの低下の原因となるSQLServerのパフォーマンスのボトルネックには、CPU、メモリ、I/Oの3つの主要なタイプがあります。原因、症状、診断はボトルネックの種類によって異なるため、注意すべき点の概要ガイドは次のとおりです。
CPUのボトルネック
原因： 不十分なハードウェアリソース
症状： 常に高いプロセッサ使用率
監視する指標： ％プロセッサ時間、バッチリクエスト/秒、SQLコンパイル/秒およびSQL再コンパイル/秒
メモリのボトルネック
原因： SQL Server、システム、またはその他のアプリケーションアクティビティによって引き起こされる使用可能なメモリの制限とメモリの負荷
症状： アプリケーションの応答性の低下、システム全体の速度低下、およびアプリケーションのクラッシュ
監視する指標： 使用可能なメモリ（KB）、合計サーバーメモリ（KB）、ターゲットサーバーメモリ（KB）、ページ/秒、チェックポイントページ/秒、レイジー書き込み/秒、バッファキャッシュヒット率
I/Oボトルネック
原因： ディスクとの間のデータベースページの過度の読み取りと書き込み
症状： 長い応答時間、アプリケーションの速度低下、タスクのタイムアウト
監視する指標： 平均ディスクキューの長さ、平均ディスク秒/読み取り、平均ディスク秒/書き込み、％ディスク時間、平均ディスク読み取り/秒、平均ディスク書き込み/秒
ヒント＃3：インデックスが適切に設計されていることを確認する
インデックスは、特定のSQL Serverの操作を高速化するための優れた方法ですが、適切に設計されている場合に限ります。不適切に設計されたインデックスは逆の効果をもたらし、SQLServerのパフォーマンスを確実に低下させる方法です。
これらの4つの領域を適切に設定すると、SQL Serverのパフォーマンスを低下させるのではなく、インデックスが適切に設計され、役立つようになります。
テーブルサイズ
すべてのテーブルがインデックス作成に適しているわけではありません。実際、テーブルが小さすぎる場合は、SQL Serverがテーブル全体を検索する方が、インデックスを検索するよりもはるかに効率的です。もちろん、大きなテーブルの場合は逆になります。そのため、インデックスの恩恵を受けるテーブルを決定する際には、潜在的なオーバーヘッドを比較検討する必要があります。
インデックスタイプ
技術的には、すべてのデータベーステーブルに1つのクラスター化インデックスと無限の数の非クラスター化インデックスを含めることができますが、「何かができるという理由だけで」と言われていることはご存知でしょう…
非クラスター化インデックスが多すぎると、挿入および更新操作が大幅に遅くなる可能性があるため、1つのクラスター化インデックスと絶対に不可欠な非クラスター化インデックスの最小数に固執することは、はるかに優れた設計上の選択です。
インデックスストレージ
設計段階では、インデックスの適切なストレージ基準を選択することがI/Oパフォーマンスにとって非常に重要です。パーティション化されたクラスター化インデックスと非クラスター化インデックスは、メインテーブルと同じファイルグループに格納することも、別のファイルグループに格納することもできます。非クラスター化インデックスを別のディスクドライブにあるファイルグループに保存すると、別のディスクドライブで発生するデータとSQLインデックスページの同時読み取りの影響を受けないため、それを使用するクエリのパフォーマンスを向上させることができます。
フィルファクター
FILLFACTORは、インデックスを作成するときに各データページで埋められるスペースのパーセンテージを指定します。 FILLFACTORの値の範囲は、0パーセント（データページがいっぱいにならない）から100パーセント（データページが完全にいっぱいになる）までです。インデックスを設計するときは、過度のインデックスの断片化のリスクを最小限に抑えながら、ページの使用を最適化するFILLFACTOR値を選択してください。
SQL Serverのパフォーマンス調整を標準ルーチンの一部にすることは、データベースを最高のパフォーマンスで実行するための優れた方法です。これらの3つの簡単な手順を通常のSQLServerメンテナンスプランに組み込むと、ユーザーの速度とパフォーマンスが大幅に向上します。