問題
これは一般的な問題であり、SQL Server を使用するすべての企業にとって深刻な問題であるため、明確にしておきましょう。
この問題と CREATE CLUSTERED INDEX の必要性は誤解されています。
永続的なクラスター化インデックスを持つことは、持たないよりも優れていることに同意しました。しかし、それは要点ではなく、とにかく長い議論につながるので、それは脇に置いて、投稿された質問に焦点を当てましょう.
ポイントは、Heapにかなりの断片化があるということです。あなたはそれを「テーブル」と呼んでいますが、物理的なデータ ストレージまたは DataStructure レベルにはそのようなものはありません。テーブルは論理的な概念であり、物理的な概念ではありません。これは、物理的な DataStructures のコレクションです。コレクションは、次の 2 つの可能性のいずれかです。
ヒープがひどく断片化されます。散在する(ランダムな)挿入/削除/更新が多いほど、断片化が多くなります。
ヒープをそのままクリーンアップする方法はありません。MS は機能を提供していません (他のベンダーが提供しています)。
解決
ただし、Create Clustered Index は、ヒープを完全に書き換えて並べ替えることがわかっています。したがって、メソッド (トリックではありません) は、 Heap の断片化を解消する目的でのみクラスター化インデックスを作成し、後でそれを削除することです。table_size x 1.25 の db の空き容量が必要です。
その際は、必ず FILLFACTOR を使用して、将来の断片化を減らしてください。その後、ヒープはより多くの割り当てられたスペースを使用し、更新による将来の挿入、削除、および行の拡張を可能にします。
ノート
断片化には 3 つのレベルがあることに注意してください。これは、クラスター化インデックスの欠如によって引き起こされる、レベル III のみのヒープ内の断片化を扱います。
別のタスクとして、別の時期に、断片化を完全に排除する永続的なクラスター化インデックスの実装を検討したい場合があります...しかし、それは投稿された問題とは別のものです。
コメントへの返信
SqlRyan:
これで私の問題に対する魔法のような解決策が得られるわけではありませんが、私の問題が SQL Server の制限の結果であり、クラスタ化インデックスを追加することがヒープを「最適化」する唯一の方法であることは明らかです。
そうではありません。それを「限界」とは言いません。
ヒープ内の断片化を解消するために私が示した方法は、クラスター化インデックスを作成してから削除することです。すなわち。一時的に、その唯一の目的は断片化を修正することです。
テーブルにクラスター化インデックスを (永続的に) 実装することは、全体的な断片化 (DataStructure は引き続き断片化される可能性があります。以下のリンクの詳細情報を参照してください) を減らすため、はるかに優れたソリューションです。これは、ヒープで発生する断片化よりもはるかに少ないです。
リレーショナル データベースのすべてのテーブル (「パイプ」テーブルまたは「キュー」テーブルを除く) には、さまざまな利点を活用するために、クラスター化インデックスが必要です。
クラスター化インデックスは、データを分散する列に配置する必要があります (INSERT の競合を回避します)。レコード ID 1など、単調に増加する列にインデックスを作成しないでください。これにより、最後のページで INSERT ホット スポットが保証されます。
1. すべてのファイルに ID を記録すると、「データベース」が非リレーショナル レコード ファイリング システムにレンダリングされます。SQL は便宜上のみ使用されます。このようなファイルには、リレーショナル データベースの整合性、パワー、または速度がありません。
Andrew Hill:
「フラグメンテーションには 3 つのレベルがあることに注意してください。これはレベル III のみを扱います」についてさらにコメントしていただけますか? -- 他の 2 つのレベルのフラグメンテーションは何ですか?
MS SQL と Sybase ASE には、3 つのレベルの断片化があり、各レベル内にいくつかの異なるタイプがあります。断片化を扱うときは、テーブルではなく DataStructures に注目する必要があることに注意してください (上記で説明したように、テーブルは DataStructures のコレクションです)。レベルは次のとおりです。
レベル I • Extra-DataStructure
関連する DataStructure の外側、データベース全体またはデータベース内。
レベル II • DataStructure
関連する DataStructure 内で、ページの上 (すべてのページにわたって)
これは、DBA によって最も頻繁に扱われるレベルです。
レベル III • ページ
関連する DataStructure 内、ページ内
これらのリンクは、断片化に関する完全な詳細を提供します。これらは Sybase ASE に固有のものですが、構造レベルでは、情報は MS SQL に適用されます。
私が示した方法はレベル II であることに注意してください。これは、レベル II および III のフラグメンテーションを修正します。