これは、最適化について尋ねられる人にいつも提供する便利なリストです。
私たちは主にSybaseを使用していますが、ほとんどのアドバイスは全面的に適用されます。
たとえば、SQL Serverには多数のパフォーマンス監視/調整ビットが付属していますが、そのようなものがない場合（おそらくある場合でも）、次のことを検討します...
問題の99％ 私が見たのは、結合に含まれるテーブルが多すぎることが原因です。 。これに対する修正は、（一部のテーブルを使用して）結合の半分を実行し、結果を一時テーブルにキャッシュすることです。次に、その一時テーブルで結合する残りのクエリを実行します。
クエリ最適化チェックリスト
- 基になるテーブルでUPDATESTATISTICSを実行します
- 多くのシステムは、これをスケジュールされた毎週のジョブとして実行します
- 基になるテーブルからレコードを削除します（削除されたレコードをアーカイブする可能性があります）
- これを1日1回または1週間に1回自動的に行うことを検討してください。
- インデックスの再構築
- テーブルの再構築（bcpデータの出力/入力）
- データベースのダンプ/リロード（大幅ですが、破損が修正される可能性があります）
- 新しい、より適切なインデックスを作成する
- DBCCを実行して、データベースに破損の可能性があるかどうかを確認します
- ロック/デッドロック
- データベースで他のプロセスが実行されていないことを確認してください
- 特にDBCC
- 行またはページレベルのロックを使用していますか？
- クエリを開始する前にテーブルを排他的にロックする
- すべてのプロセスが同じ順序でテーブルにアクセスしていることを確認します
- データベースで他のプロセスが実行されていないことを確認してください
- インデックスは適切に使用されていますか？
- 結合は、両方の式がまったく同じデータ型である場合にのみインデックスを使用します
- インデックスは、インデックスの最初のフィールドがクエリで一致した場合にのみ使用されます
- クラスター化されたインデックスは適切な場所で使用されていますか？
- 範囲データ
- value1とvalue2の間のWHEREフィールド
- 小さな結合は素晴らしい結合です
- デフォルトでは、オプティマイザーは一度にテーブル4のみを考慮します。
- これは、4つを超えるテーブルとの結合では、最適でないクエリプランを選択する可能性が高いことを意味します
- 参加を解除する
- 参加を分割できますか？
- 一時テーブルへの外部キーを事前に選択します
- 結合の半分を実行し、結果を一時テーブルに配置します
- 適切な種類の一時テーブルを使用していますか？
-
#tempテーブルは@tableよりもはるかに優れたパフォーマンスを発揮する可能性があります 大量の変数（数千行）。
-
- 要約テーブルの保守
- 基になるテーブルでトリガーを使用してビルド
- 毎日/毎時/などを構築します。
- アドホックに構築
- 段階的にビルドするか、分解/再構築します
- SETSHOWPLANONを使用してクエリプランを確認する
- SET STATSIOONで実際に何が起こっているかを確認する
- プラグマを使用してインデックスを強制します：（index：myindex）
- SETFORCEPLANONを使用してテーブルの順序を強制します
- パラメータスニッフィング：
- ストアドプロシージャを2つに分割
- proc1からproc2を呼び出す
- @parameterがproc1によって変更された場合、オプティマイザーがproc2のインデックスを選択できるようにします
- ハードウェアを改善できますか？
- 何時に走っていますか？静かな時間はありますか？
- Replication Server（または他のノンストッププロセス）は実行されていますか？一時停止できますか？それを実行します。毎時？