1

最近データベースに問題が発生したため、インデックスの状態を確認し、断片化を減らしようとしています。

アプリには、作成した User オブジェクトに属性を設定するために使用する、BoysNames や GirlsNames などの名前のテーブルがいくつかあります。ここで明らかな属性は性別です。これらのテーブルには、数百から 10,000 の行を含めることができます。

これらのテーブルは次のように構成されています。

Name - nvarchar(50) - PK & Clustered Index
DateCreated - datetime

Sql Server にすべてのテーブルのインデックスを再編成または再構築するように指示すると、ほとんどのテーブルのフラグメント化は 0% になりますが、これらの名前テーブルの一部はすぐに 50% でフラグメント化されます。

これらのテーブルには 2 つの場所でのみアクセスします。

  1. 1 つ目は、テーブルからすべての名前を選択し、それをメモリに保存して、システムに入ってきた新しいユーザーに対して使用する場合です。これにより、次のようなことができます。 M"}; これはかなり頻繁に起こります。
  2. 2 つ目は、リストに新しい名前を追加するときに、名前の存在を確認し、存在しない場合は追加します。これはめったに起こりません。

だから私が知る必要があるのは：

この高度な断片化が問題を引き起こしているのでしょうか? 再編成/再構築の直後に 50% に設定されているインデックスの断片化を 0% に減らすにはどうすればよいですか?

int を主キーとして使用して Name にインデックスを設定する必要がありましたか、それとも nvarchar が主キーとして正しい選択でしたか?

4

1 に答える 1

0

インデックス ページがメモリに常駐している場合 (行数が少ない可能性が高い)、断片化は問題になりません。クエリでそれをベンチマークできcount(*)ます。2 回目の実行から、メモリ内の速度が表示されるはずです。100% の断片化されたテーブルと 0% の断片化されたテーブルの結果を比較すると、違いは見られないはずです。

問題はないと思います。必要に応じて、100 未満の FILL FACTOR を設定して、ランダムな場所に行を挿入するときに新しい行を挿入できるようにすることができます。90 から始めて、断片化の進行率に満足するまで 5 ずつ下げます。

フィールドでクラスタリングするIDENTITYと、クラスター化されたインデックスの断片化が解消されますが、おそらくName再び断片化するインデックスが必要になるでしょう。インデックスがまったく必要ない場合は、これをヒープ テーブルにして処理を完了します。ただし、これには強くお勧めします。

于 2013-10-25T15:54:29.787 に答える