TempDBのデータファイルはいくつ使用すべきですか？
実用的な目安としては、論理CPUコア1つにつき1つのTempDBデータファイル（最大8つまで）を使用し、すべてのファイルを同じサイズに設定することです。それ以降は、競合状況や監視結果に基づいて変更を検討してください。
データベースに複数のトランザクションログファイルを使用すべきですか？
ほとんどの場合、必要ありません。適切なサイズで、増分が固定された単一のログファイルの方が管理が容易であり、通常はパフォーマンスも向上します。主な例外は、トランザクション・ログがディスク全体を埋め尽くしてしまう場合です。ログファイルを拡張する余地がなく、ログファイルが満杯になったためにそのデータベースへの書き込みが停止している場合、別のディスクに2つ目のログファイルを追加することは、短期的な対策として妥当な場合があります。それでも、データベースを単一のログファイルに戻すために、後でログを再構築するよう努めます。
パーセンテージベースの自動拡張は避けるべきですか？
必ずしもそうとは限りませんが、予測不可能性が生じます。固定サイズの自動拡張の方が理屈が分かりやすく、ファイルが大きくなるにつれてサイズが急激に跳ね上がるのを防げます。
ストレージが本当にボトルネックかどうかはどうやって判断すればよいですか？
待機統計とファイルレベルのI/Oメトリクスを長期的に確認してください。レイテンシや待機が特定のファイルや操作と一致している場合、調査すべき具体的な箇所が特定できます。
すでに過負荷状態にある場合、どこから手をつければよいでしょうか？
可視性とリスクが最も高い箇所から着手してください。具体的には、TempDB、トランザクションログのサイズ設定、および基本的なI/Oモニタリングです。これらの変更は、パフォーマンスや安定性の向上、そしてチームへの時間的還元という点で、多くの場合、すぐに成果をもたらします。
TempDBとは：
SQL ServerにおけるTempDBを一言で言うと、「SQL Serverが作業場として使う、共有のゴミ捨て場兼スクラップ帳」です。
サーバが起動するたびに新しく作成され、再起動すると中身はすべて消去されるという、非常に特殊なシステムデータベースです。
主な役割
SQL Serverは、自分自身のメモリだけでは処理しきれない時や、一時的な保管場所が必要な時にTempDBを使います。
-
一時オブジェクトの保存: ユーザーが作成した一時テーブル（
#temp）やテーブル変数などを置く場所です。 -
作業領域: 大きなデータのソート（並べ替え）、ハッシュ結合（JOIN処理）、重複削除（DISTINCT）などを行う際の作業スペースとして使われます。
-
行バージョン管理: 「スナップショット分離レベル」などを使っている場合、変更前の古いデータを一時的にここに避難させます。
TempDBの4つの大きな特徴
-
再起動でリセットされる: SQL Serverサービスを再起動するたびに、TempDBは削除され、初期サイズで再作成されます。そのため、重要なデータをここに永続保存することはできません。
-
ログ記録が最小限: 通常のデータベースと違い、リカバリ（復旧）を想定していないため、書き込みパフォーマンスを上げるためにトランザクションログの記録が簡略化されています。
-
全ユーザーで共有: 一つのインスタンス内にあるすべてのデータベースが、この一つのTempDBを共有します。
-
設定がパフォーマンスに直結する: みんなが使う「作業場」なので、ここが渋滞するとシステム全体の速度が低下します。
