sql - 2 億行を超えるテーブルでレコードを検索する

Question

テーブルではどのタイプのインデックスを使用する必要がありますか? 最初は空のテーブルに (月に 1 回) 挿入されます。次に、2 つの列に非クラスター化複合インデックスを配置します。2 つのフィールドを 1 つにマージすると、検索時のパフォーマンスが向上するかどうか疑問に思います。それとも関係ありませんか？主キーのクラスター化インデックスを持つ ID 列を使用する必要がありますか?

Answer 1

テーブルをクエリするときに使用できる一意の主キーを定義できる場合、これがクラスター化インデックスとして使用され、選択が最も高速になります。

選択クエリで前述の 2 つのフィールドを使用する必要がある場合は、それらを分離しておいてください。パフォーマンスは影響を受けず、スキーマは損なわれません。

Answer 2

「クラスター化インデックスは、値の範囲を頻繁に検索する列で特に効率的です。クラスター化インデックスを使用して最初の値を持つ行が見つかった後、後続のインデックス値を持つ行は物理的に隣接していることが保証されます。」

これを念頭に置いて、アプリケーションにとってビジネス上の意味がない限り、主キー (ID) にクラスター化インデックスを設定してもあまりメリットはないと思われます。一般的にクエリを実行する Date 値がある場合は、それにクラスター化インデックスを追加する方が理にかなっている場合があります。

select * from table where created > '2013-01-01' and created < '2013-02-01'

データ ウェアハウスが連結キー アプローチを使用しているのを見てきました。これが機能するかどうかは、クエリによって異なります。特に B ツリー インデックスのルックアップが 1 つ少ない場合は、複数のフィールドよりも 1 つのフィールド値をクエリする方が明らかに高速です。

または、テーブルに 2 億行ある場合は、データを複数のテーブルに分割することが理にかなっている場合に検討できます。

このすべてのデータを毎月読み込んでいると言っているので、すべてのデータが関連していると仮定する必要があります。「古い」と見なされ、検索に関係のないデータがテーブルにある場合は、(同じスキーマを使用して) アーカイブ テーブルにデータを移動して、クエリが「現在の」データに対してのみ実行されるようにすることができます。

それ以外の場合は、MongoDB などの NoSQL で使用されるシャーディングアプローチを検討できます。MongoDB がオプションでない場合は、アプリケーションでロジックのような同じシャード キーを実現できます。データベースの SQL ドライバーがシャーディングをネイティブにサポートするとは思えません。

Answer 3

人々がテーブルをクエリするときに、where 句で使用される可能性が最も高いフィールドにインデックスを付ける必要があります。主キーについて心配する必要はありません。すでにインデックスがあります。