IDENTITY列でクラスター化インデックスを再構築すると、何か役立つことはありますか？
非常に大きなトランザクションログテーブルを作成したCOTS製品があります。キーとして宣言されたIDENTITY列をサポートする単一のクラスター化インデックスがあります。昨夜、インデックスが再構築され、サーバーのディスク領域が不足したため、午前12時30分から稼働しています。
SQL Serverがこのインデックスを再構築するときに、SQL Serverは何かを実行するのでしょうか。すべての挿入が最後のページに入るので、リーフページやページ分割はありません。そして、行を削除することは決してありません（とにかくまだです）。
明らかにサーバーは何かを行おうとしましたが、成功した場合、テーブルは異なりますか？これは巨大なノーオペレーションであり、時間の無駄だと思っています。テーブルに非クラスター化インデックスもある場合、これは明らかに当てはまりません。そして実際に、このテーブルに追加のインデックスがあったとしても、テーブルのようにすべて追加しただけの場合は、最初にプライマリインデックスを再構築する必要はありません。
私のDBAは、すべてのインデックスをテーブルレベルではなくデータベースレベルで管理していると述べています。
追加情報
私の仮定は、ディスク上のページを再構築した後、以前と同じように見え、データベースのシャッフルに時間を浪費しているだけです。
行を削除しないので、いいえ、インデックスを再構築しても、そのインデックスの統計の更新以外に実際の値は提供されません。これは、再構築操作で暗黙的に更新されるためです。より効率的な方法は、代わりに UPDATE STATISTICS ステートメントを実行することです。
あたり ベンジャミンネバレス ：
たとえば、ALTER INDEX…REBUILDを使用してインデックスを再構築すると、WITH FULLSCANを使用した場合と同等のインデックス統計も更新されます。
他の質問に答えるには：
テーブルは違うのでしょうか？
別のページアドレスにあることを除いて、構造的には違いはないでしょう。
テーブルに非クラスター化インデックスもある場合、これは明らかに当てはまりません。
クラスタ化インデックスを再構築しても、テーブルに関連付けられている非クラスタ化インデックスは自動的に再構築されません。これを行うには、クラスター化インデックス名の代わりにキーワードALLを指定する必要があります。単位 [〜＃〜] ms [〜＃〜] ：
...
ALTER INDEX…REBUILDを使用してクラスター化インデックスを再構築しても、デフォルトでは非クラスター化インデックスは再構築されません...すべてのインデックスを再構築するには、インデックス名にALLを指定する必要があります。
そして最後の質問：
このテーブルに追加のインデックスがあったとしても、テーブルのように追加しただけの場合は、最初にプライマリインデックスを再構築する必要はありません。
正しい。テーブルの最後に追加された後にレコードを変更しない場合は、以下のスコットホジンのコメントで特定されている Ascending Key Problem を回避するために、統計情報を更新するだけで十分です。