問題タブ [clustered-index]

タイムスタンプに降順でクラスター化されたインデックスがあることに気付きました。昇順に切り替えて、増え続ける新しいタイムスタンプが挿入されると、それらがテーブルの最後に追加されるようにすることを考えています。現状では、テーブルの先頭に行を追加する必要があると思われますが、SQL Server がそれをどのように処理するのか疑問に思っています。

テーブルの先頭に新しいページを効率的に割り当て、それらのページに新しい行を効率的に挿入できますか、それともタイムスタンプの順序でページを埋め、最後に昇順のクラスター化インデックスを使用して新しいページを割り当てる方がよいでしょうか。

PRIMARY KEYキーワードは、SQL Serverのクラスター化インデックスとどのように関連していますか？

（私が尋ねた別の質問ではなく、この質問に答えたいと思う人もいるようです。そのため、より良い場所を提供しています。）

SQL Serverでテーブルにクラスター化インデックスがある場合、それはすべてのインデックス付きクエリがクラスター化インデックスを経由することを意味しますか？

たとえば、単一の非クラスター化インデックス（1つの列にインデックスを付ける）を持つテーブルがあり、その列を介して行を検索すると、次のようになります。Index Seek -> RID -> Data row lookup -> Result

しかし、別の列にクラスター化インデックスを追加すると、同じクエリで次のようになりますIndex Seek -> Extract clustering key -> Clustered index seek -> Results

これは、非クラスター化インデックスがリーフのRIDではなく、クラスター化インデックスのクラスター化キーで「終了」することを意味しますか？そうですか？

私の2つの質問は次のとおりです。

• クラスタ化インデックスを使用して、大きなテーブルへの一括挿入を高速化できますか？
• IDENTITY列がクラスター化インデックスではなくなった場合でも、外部キー関係を効率的に使用できますか？

詳細に説明すると、会社のデータを含む非常に大きな（100〜1000百万行の）テーブルがいくつかあるデータベースがあります。通常、このようなテーブルには20〜40の企業に関するデータがあり、それぞれが「CompanyIdentifier」（INT）でマークされた独自の「チャンク」です。また、すべての企業には約20の部門があり、それぞれに「DepartmentIdentifier」（INT）でマークされた独自の「サブチャンク」があります。

「チャンク」または「サブチャンク」全体がテーブルに追加またはテーブルから削除されることがよくあります。私が最初に考えたのは、これらのチャンクでテーブルパーティショニングを使用することでしたが、SQL Server 2008 Standard Editionを使用しているため、その資格がありません。それでも、私が持っているほとんどのクエリは、テーブル全体ではなく、「チャンク」または「サブチャンク」で実行されます。

私はこれらのテーブルを次の機能のために最適化するために取り組んできました：

1. サブチャンクで実行されるクエリ
2. テーブル全体で実行される「ベンチマーク」クエリ
3. データの大きなチャンクの挿入/削除。

1）と2）については、私は多くの問題に遭遇していません。キーフィールド（有用な場合はCompanyIdentifierとDepartmentIdentifierも含む）にいくつかのインデックスを作成しましたが、クエリは正常に実行されています。

しかし、3）私は良い解決策を見つけるのに苦労しました。私の最初の戦略は、常にインデックスを無効にし、大きなチャンクを一括挿入し、インデックスを再構築することでした。これは最初は非常に高速でしたが、データベースに多くの企業が存在するようになったため、毎回インデックスを再構築するのに非常に長い時間がかかります。

現時点では、これがより高速になっているように見えるため、私の戦略は挿入中にインデックスをオンのままにすることに変更されました。しかし、挿入速度をさらに最適化したいと思います。

CompanyIdentifier + DepartmentIdentifierで定義されたクラスター化インデックスを追加することにより、テーブルへの新しい「チャンク」のロードが高速になることに気付いたようです。IDENTITY列にクラスター化インデックスを追加するためにこの戦略を放棄する前は、クラスター化インデックスは他のすべてのインデックスに含まれているため、クラスター化インデックスはできるだけ小さくする必要があると指摘されていました。しかし今、私はこの古い戦略を復活させてインサートをスピードアップすることを考えています。私の質問ですが、これは賢明なことでしょうか、それとも他の分野でパフォーマンスの低下に見舞われるのでしょうか？そして、これは本当に私の挿入をスピードアップしますか、それともそれは私の想像力ですか？

また、私の場合、IDENTITY列が本当に必要かどうかもわかりません。他のテーブルとの外部キー関係を確立できるようにしたいのですが、CompanyIdentifier + DepartmentIdentifier + [uniquifier]スキームのようなものを使用することもできますか？または、テーブル全体の断片化されたIDENTITY番号である必要がありますか？

提案や説明をありがとうございました。

私はJava Tutorialを通して自分の道を歩もうとしています。

著者は、MS SQL を操作するためのチュートリアルを作成しました。MySQL を使用してチュートリアルに従いたいと思います。以下に示すように、"IDENTITY"、"CONSTRAINT"、および "CLUSTERED" を使用する MS SQL スクリプトをどのように変換するか完全にはわかりません。

これは私がそれを手に入れることができた限りです：

...しかし、省略されたコードにより機能が失われ、チュートリアルの残りの部分と互換性がなくなることさえ懸念されます。

これを書くより良い方法はありますか？

クラスター化インデックスには、インデックス フィールドだけでなく、すべての行データが含まれていることがわかりました。断片化に関して、これが意味することを理解しようとしています。

次のようなテーブルがあるとします。

ここで、これらの行がすべてデータでいっぱいで、クラスター化インデックスの以前の行のいくつかで、Field1、Field2、Field3、および Binary を突然 null に設定したとします。

これが意味することの 1 つは、私の単純な考え方ですが、これらの値をすべて消去するとギャップが生じ、インデックスが断片化することです。行はまだ正しい順序になっていると思いますが、それは本当にインデックスの断片化ですか?

または、別の方法で考えることができます。それらがすべて最初から null で、データを挿入する場合、データを別のページにシャッフルしなければならず、インデックスの断片化も発生しますか?

さらに、LOB データが別のアロケーション ユニットに格納されていることは知っていますが、それが何を意味するのかはわかりません。Binary を null に設定 (または設定) しても、クラスター化インデックスの断片化には影響しないということですか?

合計最大サイズが8kの境界を大幅に超える列が多数あるテーブルがあります。このテーブルには、基本的にそれがどのタイプのオブジェクトであるかを示すModuleID列が含まれています（心配しないでください-私はこれを設計していません）。そのうち15の異なる値が存在する可能性があります。そして、それは、IDENTITY（1,1）でもあり、SQLServerによってインクリメントされるpropertyIDと呼ばれる一意の列を持っています。ModuleIDにはクラスター化されたインデックスがあり、この値はselectで常に認識され、更新ではpropertyIDが使用されます（moduleIDがここでスコープ内にあることはめったにありません）。テーブルには数百万行が含まれています。

INSERTに関して、私の質問は次
のとおりです。a）一意でないクラスター化されたキーは、SQL ServerがKEY（行）ロックの代わりに排他的なページレベルのロックを保持する可能性を高めますか？
b）クラスター化されたキーをインクリメントされる一意のpropertyIDに変更すると、SQL Serverは代わりに排他的なKEYロックを保持できるようになり、これらは常にクラスター化されたインデックスの最後のページに移動しますか？

テーブルが（一部のインストールでは）moduleIDでパーティション化されているという事実は、あなたの答えを変えますか？

デフォルトでは、MongoDB はドキュメントの _id キーにインデックスを作成します。しかし、追加のインデックス (MySQL の InnoDB のようにセカンダリ?) を確認してクエリを実行すると、エンジンはそれをスキャンし、_id インデックスを選択的にスキャンしてドキュメントのオフセットを取得しますか?

シャーディングが来ると、すべてのチャンクに独自のインデックスがあり、クエリごとに多くのランダム読み取りがあるので、私は混乱していますか?

私の同僚の1人は、SQL Server 2008のテーブルにインデックスを追加すると、PKのインデックスもそのインデックスに追加されるという印象を受けています。したがって、より広い主キーを使用している場合、そのキーも新しいインデックスに含まれ、PKのインデックスにすでに支払われているペナルティを超えて使用されるディスク容量が大幅に増加します。私はそれを前に聞いたことがなく、これまでの私の検索は空っぽになっています。

うまくいけば、ここの誰かがこれを確認または拒否するために関連するドキュメントを私に指摘することができます。お願いします？

これからアドバイスをお願いします。オブジェクトを追跡したいテーブルと、オブジェクトに関連するキーのリストを取得しました。例：

OBJECTIDとITEMKEYはどちらも高い選択性を持っています（つまり、OBJECTIDとITEMKEYは非常に多様です）。私のアクセスは2つの方法です：

• オブジェクトID別：オブジェクトが変更されるたびに、キーのリストが変更されるため、オブジェクトIDに基づいてキーが必要になります。変更は頻繁に発生します。

• ITEMKEYによる：これはキーワード検索用であり、頻繁に発生します。

したがって、おそらく2つのキーが必要であり、クラスター化されたインデックス用に1つを選択します（より頻繁にアクセスされるキー、または速度を上げたい場所で、今のところ、クラスター化されたオブジェクトIDを優先すると仮定します）。私が混乱しているのは、それをどのように設計すべきかということです。

私の質問は、どちらが良いかです：

a）（OBJECTID、ITEMTYPE、ITEMKEY）のクラスター化されたインデックス、次に（ITEMKEY）のインデックス。私の懸念は、クラスター化されたインデックスが非常に大きいため（2 int、1 string）、すべてのインデックス項目がクラスター化されたキーを指すようになるため、インデックスが大きくなることです。

b）実行中のID DIRECTORYID（整数）を主キーおよびクラスター化インデックスとして使用して新しい列を作成し、（OBJECTID、ITEMTYPE、ITEMKEY）と（ITEMKEY）の2つのインデックスを宣言します。これにより、インデックススペースが最小限に抑えられますが、ルックアップコストが高くなります。

c）（OBJECTID、ITEMTYPE、ITEMKEY）のクラスター化インデックス、およびその上の（ITEMKEY、ITEMTYPE、OBJECTID）のマテリアライズド・ビュー。私の論理では、これはキールックアップを回避し、オーバーヘッドが高くなる代わりに、a）のルックアップを使用したインデックスと同じ大きさになります。

d）えーと...要件を考えるともっと良い方法があるのでしょうか？

よろしくお願いします、アンドリュー