上記の Marc と Unkown に同意します ... クラスター化インデックスの 6 つのインデックスは、特に 14 列しかないテーブルでは多すぎます。 3 つまたは 4 つを超えてはなりません。その場合、1 つまたは 2 つと言います。クラスター化インデックスはディスク上の実際のテーブルであることをご存知かもしれません。そのため、レコードが挿入されると、データベース エンジンはそれを並べ替えて、ディスク上のソートされた整理された場所に配置します。非クラスター化インデックスはそうではなく、ルックアップ 'テーブル' をサポートしています。私の VLDB は、以下の 1 番目のポイントに従ってディスク (CLUSTERED INDEX) に配置されています。
<オール> クラスタ化インデックスを 1 または 2 に減らします。最適なフィールドの選択肢は、IDENTITY (INT) (ある場合)、またはフィールドがデータベースに追加される日付フィールド、またはその他のフィールドです。データがデータベースに追加される自然な並べ替え。ポイントは、そのデータをテーブルの一番下に保持しようとしているということです... または、レコードを読み取るのに最適な (90% 以上) 方法でディスクに配置します。これにより、再編成が行われないか、最適な読み取りのために適切な場所にデータを取得するために 1 回のヒットしかかからないようになります。削除されたフィールドは必ず非クラスター化インデックスに入れて、ルックアップの有効性を失わないようにしてください。 VLDB に 4 つ以上のフィールドを配置したことはありません。頻繁に更新されるフィールドがあり、それらがクラスター化インデックス OUCH に含まれている場合、ディスク上のレコードが再編成され、COSTLY の断片化が発生します。
インデックスの fillfactor を確認します。フィル ファクタ数 (100) が大きいほど、データ ページとインデックス ページがいっぱいになります。レコードの数と挿入するレコードの数に関連して、非クラスター化インデックスのフィルファクター # (+ または -) を変更して、レコードが挿入されるときにフィル スペースを許可します。クラスター化インデックスをシーケンシャル データ フィールドに変更しても、クラスター化インデックスではそれほど問題になりません。経験則 (IMO)、高書き込みの場合は 60 ～ 70、中程度の書き込みの場合は 70 ～ 90、高読み取り/低書き込みの場合は 90 ～ 100 です。 fillfactor を 70 に下げると、ページ上の 100 レコードごとに 70 レコードが書き込まれ、新しいレコードまたは再編成されたレコード用に 30 レコードの空き領域が残ることになります。より多くのスペースを消費しますが、毎晩 DEFRAG を実行するよりはましです (以下の 4 を参照)
テーブルに統計が存在することを確認します。 "sp_createstats 'indexonly'" を使用してデータベースをスイープして統計を作成する場合、SQL Server は、必要な統計としてエンジンが蓄積したすべてのインデックスに関するすべての統計を作成します。ただし、'indexonly' 属性を省略しないでください。そうしないと、すべてのフィールドに統計情報を追加することになり、適切ではありません。
DBCC SHOWCONTIG を使用してテーブル/インデックスをチェックし、どのインデックスが最も断片化されているかを確認します。ここでは詳細には触れませんが、実行する必要があることだけは知っておいてください。次に、その情報に基づいて、インデックスが経験している変化と (経時的な) 変化の速さに応じて、fillfactor を上下に変更します。
個々のインデックスでオンライン (DBCC INDEXDEFRAG) またはオフライン (DBCC DBREINDEX) で実行するジョブ スケジュールを設定して、最適化します。警告:この大きなテーブルで DBCC DBREINDEX を実行しないでください。メンテナンス時間中でなければ、アプリがダウンする可能性があります。特に CLUSTERED INDEX では。あなたは警告されました。この部分をテストしてテストしてください。
実行計画を使用して、存在する SCANS と FAT PIPES を確認し、インデックスを調整してから、ストアド プロシージャを最適化および書き換えて、これらのホット スポットを取り除きます。実行計画に RED オブジェクトが表示される場合は、そのフィールドに統計がないためです。良くないね。このステップは「科学というより芸術」です。
オフピーク時には、UPDATE STATISTICS WITH FULLSCAN を実行して、クエリ エンジンにデータ分布に関するできるだけ多くの情報を提供します。それ以外の場合は、平日の夜間にテーブルに対して標準の UPDATE STATISTICS (標準の 10% スキャンを使用) を実行するか、観察に応じてより頻繁に実行して、効率的にデータを取得するためのデータ分布に関する詳細情報をエンジンが確実に取得できるようにします。
長くなって申し訳ありませんが、非常に重要です。ここでは最小限の情報しか提供していませんが、非常に役立ちます。これらのポイントで使用される戦略には、時間とテストが必要ないくつかの直感と観察があります。
Enterprise エディションに移動する必要はありません。私は、パーティショニングで以前に話された機能を取得するために行いました。しかし、私は特に、検索とオンライン DEFRAGING およびメンテナンスにより、はるかに優れたマルチスレッド機能を備えているようにしました。 Standard エディションでは、オンライン データベースでの DBCC INDEXDEFRAG も処理されません。
