問題タブ [clustered-index]

テーブルにインデックスを追加したいと考えています。テーブルにインデックスを追加する方法の一般的なアイデアを探しています。クラスター化された PK 以外。これを行うときに何を探すべきかを知りたいです。だから、私の例：

このテーブル (TASK テーブルと呼びましょう) は、アプリケーション全体で最大のテーブルになります。数百万のレコードを期待しています。

重要: 大量の一括挿入により、このテーブルにデータが追加されます

テーブルには 27 列あります: (これまでのところ、カウント :D )

int x 9 列 = id-s

varchar x 10 列

ビット×2列

日時×5列

整数列

これらはすべて INT ID ですが、通常はタスク テーブル (最大 10 ～ 50 レコード) よりも小さいテーブルからのものです。例: ステータス テーブル (「オープン」、「クローズ」などの値) または優先度テーブル (「」などの値)重要」「あまり重要ではない」「普通」）「親ID」（自己ID）みたいな欄もあります

結合：すべての「小さな」テーブルにはPKがあり、通常の方法で...クラスター化されています

文字列列

「常に5文字の長さ」のような（会社）列（文字列！）があり、すべてのユーザーはこれを使用して制限されます。タスクに 15 の異なる「会社」がある場合、ログインしたユーザーには 1 つしか表示されません。したがって、これには常にフィルターがあります。この列にインデックスを追加することをお勧めしますか?

日付列

彼らはこれらを索引付けしていないと思います...そうですか？それともできる/すべきですか？

わかりました、もう一度詳しく説明する必要があります。オンラインで記事を読みましたが、まだ決定的な答えが見つかりません。

SQL Server 2008 には、約 50,000 レコードの「コア」テーブルと、すべてのクエリで同じ方法で使用される多数の読み取りアクティビティがあります。このデータは 1 か月に 1 回更新され、1 秒間に数百回読み取られます。

データは頻繁にアクセスされるため、フィールドにクラスター化されたインデックスがあります。クラスター化インデックスが次のようになっているとします。

クラスタ化されたインデックス

現在、それよりも多くのデータはありません。そのため、余分な列を「含まれる列」に入れることは理にかなっていますが、SQL Server ではクラスター化インデックスに列を含めることはできません。

したがって、クラスター化インデックスと本質的に同じフィールドを持つ 2 番目のインデックスがあり、他の列は "含まれる列" です。しかし、私が読んだことから、これは冗長であると思いますか?

COVERING INDEX (非クラスター化)

含まれる列

非クラスター化インデックスには、クラスター化インデックスの列が既に定義されていますか?

もしそうなら、どのようにしてこの 2 番目のインデックスをまったく列なしで作成できますか (クラスター化インデックスに既に含まれているもの以外に)? 言い換えれば、「このインデックスはクラスター化インデックスとまったく同じです... いくつかの列が含まれています」と言いたいのです。

それとも、すべての列 (レコードを識別しない 2 つを含む) をクラスター化インデックスに入れる方がよいでしょうか? varchar 列はより頻繁に (月に 1 回ではなく 1 日に数回) 更新されるため、クラスター化インデックスから除外したかったのですが、それらは十分に深いため、インデックス ツリーは、変更が発生したときにリバランスを引き起こすのに十分です。

では、このテーブルのすべての列がテーブルに戻らずにインデックスを介して利用できるように、これらのインデックスを設定する効率的な方法はありますか?

従業員の詳細を格納するSQLServerテーブルがあります。列IDはGUIDタイプで、列EmployeeNumberはINTタイプです。ほとんどの場合、結合と選択基準を実行している間、EmployeeNumberを処理します。

私の質問は、ClusteredIndexをEmployeeNumberに割り当てながら、PrimaryKeyをID列に割り当てることが賢明かどうかです。

編集

@Remus がテスト パターンを修正しました。以下の彼の回答で修正版を見ることができます。

INT を DECIMAL(29,0) に置き換えることを提案したところ、結果は次のようになりました。

10 進数: 2133
GUID: 1836

わずかに大きな行であっても、ランダム挿入はまだ勝っています。

ランダムな挿入はシーケンシャルな挿入よりも遅いことを示す説明にもかかわらず、これらのベンチマークはそれらが明らかに速いことを示しています。私が得ている説明は、ベンチマークと一致していません。したがって、私の質問は引き続き b ツリー、順次挿入、および速度に焦点を当てています。

...

経験から、B ツリーにデータが (方向に関係なく) 順次追加されると、パフォーマンスが大幅に低下することがわかっています。ただし、データをランダムに追加すると、最高のパフォーマンスが得られます。

これは、RB ツリーなどを使用して簡単に実証できます。順次書き込みにより、最大数のツリー バランスが実行されます。

二分木を使用するデータベースはほとんどなく、n 次のバランスの取れた木を使用していることは知っています。シーケンシャルな入力に関しては、バイナリ ツリーと同様の運命をたどると論理的に想定しています。

これは私の好奇心を刺激しました。

その場合、シーケンシャル ID (IDENTITY(1,1) など) を書き込むと、ツリーの複数のリバランスが発生すると推測できます。「これらはランダムな書き込みを引き起こす」として、多くの投稿が GUID に反対しているのを見てきました。私は GUID を使用したことはありませんが、この「悪い」点が実際には良い点であることに気づきました。

だから私はそれをテストすることにしました。これが私のコードです：

GUID の作成や、行のかなりの余分なサイズのために時間を差し引いていないことに注意してください。私のマシンでの結果は次のとおりです。

Int: 17,340 ミリ秒 GUID: 6,746 ミリ秒

これは、このテストでは、16 バイトのランダム挿入が 4 バイトの順次挿入よりもほぼ3 倍高速であることを意味します。

これについてコメントしたい人はいますか？

Ps。これは質問ではないことがわかりました。これは議論への招待であり、最適なプログラミングの学習に関連しています。

大量の行を選択する必要がある大きなテーブルがあります。

このテーブルには、コール詳細レコード（CDR）が格納されます。例：

私のクエリは特定の日付の顧客からの電話を探すので、次のようにクラスター化されたインデックスでcalldateとアカウントコードを一緒にインデックス付けしました。

ただし、次のクエリを実行すると、EXPLAINの結果は、キーの日時部分のみが使用されていることを示しています。

クエリ：

EXPLAIN結果：

最初の8バイト（キーの日付部分）のみが使用されているようです。ただし、WHERE句はキーの両方の部分をANDで明示的に参照するため、理論的には完全なキーを使用する必要があります。

calldateとaccountcodeに別々のインデックスを作成し、クエリオプティマイザーにそれらをマージさせる必要がありますか？フルインデックスが使用されていないのはなぜですか？

助けてくれてありがとう！

いくつかのフィールドにまたがるクラスター化されたインデックスがあります。これらのフィールドの1つはCustomerIDです。そのテーブルから読み取り、CustomerIDを更新するカーソルがあります。問題は、それが無限ループを引き起こすことです。customeridフィールドを変更すると、クラスター化されたインデックスが変更され、インデックス用にテーブルが再構築されると思います。この変更によりカーソルが無効になるため、FETCHNEXTFROMカーソルが最後に到達することはありません。

カーソルが終了するまでテーブルがクラスター化インデックスのテーブルを更新しないようにするために発行できるコマンドはありますか？

psql を使用して postgres データベースにアクセスしています。テーブルのメタデータを表示するときに、テーブルのインデックスがクラスター化インデックスかどうかを確認する方法はありますか?

テーブルの PRIMARY KEY はクラスター化インデックスに自動的に関連付けられると聞きましたが、本当ですか?

パーティション関数とスキームが使用可能であるにもかかわらず、パーティション化されていないテーブルにパーティション化インデックスを作成する方法。それは私がどこかで読んだ演習であり、実際の問題ではありません

考えていた

しかし、テーブルはパーティション化されていないので、テーブルをパーティション化せずにインデックスを作成するにはどうすればよいですか？

indexテーブルに適切なものを追加する必要があり、助けが必要です。

私は混乱しており、いくつかの点を明確にする必要があります:

• non-int列にインデックスを使用する必要がありますか? なぜ/なぜしないのか

• 私はインデックスclusteredとnon-clusteredインデックスについて多くのことを読みましたが、どちらをいつ使用するかをまだ決定できません。良い例は、私と他の多くの開発者を助けるでしょう。

頻繁に更新される列やテーブルにはインデックスを使用すべきではないことはわかっています。他に注意すべきことはありますか?また、テスト フェーズに進む前に、すべてが正常であることをどのように確認できますか?

この 2007 年のホワイト ペーパーでは、クラスター化インデックスとして編成されたテーブルと、CI と同じキー列に非クラスター化インデックスを使用してヒープとして編成されたテーブルでの個々の select/insert/delete/update および range select ステートメントのパフォーマンスを比較しています。テーブル。

一般に、クラスター化インデックス オプションは、維持する構造が 1 つしかなく、ブックマーク ルックアップの必要がないため、テストでより優れたパフォーマンスを示しました。

このホワイト ペーパーで取り上げられていない、潜在的に興味深いケースの 1 つは、ヒープ上の非クラスター化インデックスとクラスター化インデックス上の非クラスター化インデックスの比較です。その場合、NCI リーフ レベルで SQL Server がクラスター化インデックスをトラバースするのではなく、直接追跡する RID を持っているため、ヒープのパフォーマンスがさらに向上することを期待していました。

この分野で実施された同様の正式なテストを知っている人はいますか?もしそうなら、結果はどうでしたか?