1

SQL Serverデータベースに、「一般的な」使用規則に従わないかなり一意のテーブルがあり、クラスター化インデックスに関するアドバイスを探しています。

これは作り上げられた例ですが、実際のデータにかなり厳密に従っています。

このテーブルには、他のテーブルへの実際の外部キーである3列の主キーと、関連データを含む4番目のフィールドがあります。この例では、テーブルが次のようになっているとしましょう。

CREATE TABLE [dbo].[WordCountsForPage](
 [AuthorID] [int] NOT NULL,
 [BookID] [int] NOT NULL,
 [PageNumber] [int] NOT NULL,
 [WordCount] [int] NOT NULL
)

したがって、4番目のフィールドが一意のデータである、やや階層的な主キーがあります。

実際のアプリケーションでは、合計28億の可能なレコードがありますが、それだけです。データは時間の経過とともに計算されるため、レコードはその場で作成されます。現実的には、これらのレコードの1/4だけが実際に計算される可能性があります。計算はコストのかかる操作であり、一意の組み合わせごとに1回だけ実行するため、これらはDBに保存されます。

現在、データは1分間に数千回読み取られますが、（少なくとも今のところ）テーブルが自動的に読み込まれるため、1分間に数百の挿入があります（これはかなりの時間続きます）。（今日）挿入ごとに10回の読み取りがあると言えます。

クラスター化されたインデックスのために、これらすべての挿入でパフォーマンスが低下しているのではないかと思います。

クラスター化インデックスは、テーブルが最終的に読み取り専用になるため、「長期的」に意味がありますが、そこに到達するには時間がかかります。

大量の挿入期間中にインデックスを非クラスター化し、テーブルにデータが入力されるとクラスター化に変更できると思いますが、クロスオーバーポイントがいつになるかをどのように決定しますか（そして将来どのように通知できますか） 「時が来た」）？

私が本当に必要としているのは、将来の魔法の時期に非クラスター化からクラスター化に移行するコンバーチブルインデックスです。

これを処理する方法について何か提案はありますか？

4

1 に答える 1

3

実際、私は最初に非クラスター化インデックスを作成し、後でそれをクラスター化インデックスに変換しようとすることを気にしません（それだけで本当に厄介な問題です！）。

インデックス作成の女王、キンバリー・トリップが彼女のクラスター化インデックスの議論の続きで説明しているように、テーブルにクラスター化インデックスを設定すると、実際にINSERTのパフォーマンスを向上させることができます。

挿入は、ヒープと比較して、クラスター化されたテーブル（ただし「正しい」クラスター化されたテーブルのみ）で高速です。ここでの主な問題は、ヒープ内の挿入場所を決定するためのIAM / PFSでのルックアップが、クラスター化されたテーブル（挿入場所がわかっている場合、クラスター化されたキーによって定義される）よりも遅いことです。順序が定義されているテーブル（CL）に挿入すると、挿入が高速になり、その順序が増え続けます。

ヒープは、クラスター化インデックスが定義されていないテーブルです。

これと、ヒープからクラスター化インデックスを持つテーブルに移動するのにかかる労力と手間を考慮すると、私は気にしないでしょう。インデックスを定義して、そのテーブルの使用を開始してください。

于 2010-12-04T08:51:34.247 に答える