インデックスを使用しないのが最善かどうかについて、いくつか質問があります。
背景：私のレコードにはタイムスタンプ属性があり、レコードはタイムスタンプの順に挿入されます（つまり、時系列で挿入されます）。
質問：
インデックスを使用しない場合、データベースはレコードが挿入された順序でレコードを挿入するのが一般的ですか？
＃1の答えが「はい」の場合、「SELECT ..WHEREタイムスタンプ>X」タイプのクエリを実行すると、データベースは効率的になりますか、それともインデックスが作成されていないため、すべてのレコードを処理する必要がありますか？インデックスがない場合、データベースはレコードがソートされた順序で挿入されたことを「認識」しないため、データベースのソートされたプロパティを利用できないと思います。
これらのタイプのレコードとその挿入には、クラスター化されたインデックスが最適であると思います。
皆さんの感想を教えてください。
ありがとう、jbu
私の経験では、はい、特に何も削除しない場合、データベースは時系列で物を挿入します。ただし、それは保証されていません。保証されていない動作に依存しようとするのは、本当に悪い考えです。
また、クエリ プランナーはこの事実を認識しないため、インデックスなしでクエリを実行すると、フル テーブル スキャンが発生します。インデックス付きクエリよりも遅いかどうかは、データの種類と、クエリの "X" の後に続くデータの割合に大きく依存します。
クラスター化されたインデックスは、レコードがディスク上に存在する順序です。ディスク上に順序がなければならないため、指定するかどうかに関係なく、常に1つあります。
主キーがクラスター化インデックスでもあるのは正常ですが、そうである必要はありません。
バッチ挿入を実行している場合、同じタイムスタンプで複数のレコードが挿入される可能性があります。明らかに、これを主キーにすることはできません。
「SELECT..WHEREtimestamp> X」のようなクエリを実行するには、「timestamp」フィールドのインデックスを使用すると、クラスター化されているかどうかに関係なく、そのクエリのパフォーマンスが向上します。
'timestamp'フィールドのインデックスをクラスター化する必要があるかどうか、および他のインデックスも必要かどうかは、データに対して実行する必要のあるすべてのクエリによって異なります。
もちろん、使用しているデータベースによって異なります。
一般に、実行する挿入が多い場合は、インデックスを無効にして挿入を実行してから、インデックスを再作成することをお勧めします。
タイムスタンプをクラスター化インデックス (つまり、行が格納される順序) として使用することは、最も一般的なクエリが時間順である場合 (retrieve-this-row ではなく)、および重複するタイムスタンプがない場合にのみ問題になります。
テーブルからの削除がまったくない場合は、データベースが新しいブロックをテーブルの最後に追加するだけであると想定できます。ただし、ディスク上のこれらのブロックが連続しているかどうか、または適切に進行しているかどうかについての保証はありません (つまり、時間の経過とともにテーブルが断片化される可能性があります)。
インデックスのないテーブルから SELECT を実行すると、テーブル スキャンが発生します。インデックスは、「タイムスタンプが昇順である」などのことをデータベースに「伝える」方法です。
クラスター化インデックスは、テーブル内で行をインデックス順に保持することをデータベースに伝えるのに適しています。ただし、通常、(実装によっては) 合理的に静的なデータでのみ価値があります。これは、テーブルを再構築することによって、DB がテーブルの行が実際にインデックス順であることを保証する唯一の方法であるためです。
何のデータベース？
1)
インデックスのないテーブルはヒープと呼ばれます。ヒープには、レコードが挿入された順序で格納されます。複数のスレッドから挿入しない限り、データベースがレコードを格納する順序を予測できます。他の人が指摘しているように、これは削除を行わないことを前提としています。空のページを新しい行で埋めます。
2)
インデックスがない場合、DBMS は完全なテーブル スキャンを実行する必要があります (レコード数に比例して線形時間で実行されます)。タイムスタンプが増加するレコードを挿入するレコードの場合は、クラスター化インデックスが適しています。古いタイムスタンプを挿入しない限り、DBMS はクラスター化インデックスのために行を物理的に再配置する必要があります。
SQL標準によれば、順序付けされていない列の行を選択する順序については、決して確信が持てないと思います。特定のデータベースをテストし、それが現在真であることがわかったとしても、データベースの次のリビジョンではそうではない可能性があります。私の経験秒スティーブンロウズ。テーブルに多数の行を挿入する場合は、挿入する前に行を無効（または削除）にしてください。挿入後にインデックスを再作成すると、インデックスをオンにして挿入するよりも時間がかかりません。
アラン
投稿者のjbuです。
みんなの素早い入力に感謝します。
さらに質問に答えるには:
はい、静的データがあります。削除しません。
Sybase SQL Anywhere、Oracle Berkeley DB、H2、Firebird、SQLite、およびおそらく他のいくつかのデータベースをテストしています。
Steven Lowe へ: 私のテーブルには何百万ものレコードが含まれます (最大で 32GB まで増加します)。インデックス作成をしばらくオフにしてからインデックスを再作成すると、非常に長い時間がかかりませんか? 少なくとも数分かかります (もっと時間がかかると思います)。また、挿入の連続の流れに途切れがあると想定していると思います。私はほぼ常にバッチ挿入コミットを使用して挿入を行っているため、CPU とディスクが再インデックス作成のために実際に中断することはないと思います。
繰り返しますが、入力してくれてありがとう。
Jbu
それは典型的ですが、特定の実装によって保証されているわけではありません。そのため、それに依存するのは賢明ではありません。クエリ オプティマイザもそれに依存しないため、テーブル スキャンを実行します。
あなたの場合のタイムスタンプのクラスター化インデックスには、実際にはマイナス面はありません。データ ページの 100% を埋めることもできますが、それでもヒープより悪くはありません。ただし、クエリはそれを利用することができ、わずかに (テーブルの 90% などを返す場合) から途方もなく (テーブルの 1% などを返す場合) 速くなります。 .
私のタイムスタンプを検索できるようにするには、タイムスタンプ列にインデックスを作成する必要があります。ジャスト・ドゥ・イット (TM)。
クラスター化インデックスは、主キーで検索する場合にのみ役立ちます。それを利用するために、タイムスタンプを主キーにすることができます。