聖なる牛、あなたはここで多くの質問をしています。これを分解してみましょう。
Q：SQLは既存の行を「移動」してクラスタリングを維持しますか、それともテーブルを「断片化」させますか？
データベースをページのコレクションと考えてください。机の上に文字通りの紙が並べられています。今のところ辞書について考えてみてください。辞書にさらに単語を追加したい場合は、ページに空のスペースがある場合は、それらを所定の位置に追加できます。
空の辞書から始めたとき、これは比較的簡単です。しかし、何千もの紙のページが満載された成熟した辞書について考えてみてください。
その成熟した辞書に単語をさらに追加したい場合は、ページにスペースが残っていない可能性があります。SQL Serverはページを「引き裂く」-新しいページを別の場所に移動し、単語の一部をその新しいページに移動します。新しいページは辞書の最後になります。良い知らせは、そのアクションの直後に、辞書の最後と半分に空のページがあり、どちらも単語を追加するスペースがあります。
あなたがたまたまその順序でそれらを追加しているなら、それはです。（これが、データのロード方法がますます重要になる理由です。）
インポートが一度に1行ずつ実行されると、パフォーマンスに大きな影響を与える可能性がありますか？
1秒のインデックスを忘れます-一度に1行ずつデータを追加することは、インデックス構造に関係なく、まったく非効率的です。SQL Serverはセットベースのシステムです-セットで作業できるときはいつでもそうするべきです。
データをクエリするとどうなりますか？
あなたはこれを尋ねませんでしたが、私はあなたにそれを尋ねています、ハハハ。
挿入後のことを思い出してください。これでほとんど順序付けされた辞書が手に入りましたが、辞書のいくつかのポイントに到達したら、後ろにジャンプして他のいくつかのページから読む必要があります。これらのページがすべてメモリ（RAM、バッファプールなど）にキャッシュされている場合、オーバーヘッドはそれほど大きくなりません。とにかくほとんどのメモリアクセスはランダムです-SQL Serverが辞書をメモリに順番に格納するのとは異なります。
一方、従来の磁気ハードドライブからデータを取得する必要がある場合（回転する錆）、そのデータが順番に格納されていると、パフォーマンスが少し向上する可能性があります。ただし、ここでの実際の設計目標は、データをドライブから取得するのではなく、RAMから取得することです。ディスク上の最適化されたデータとディスク上の断片化されたデータの違いは、ディスクから取得した場合とRAMから取得した場合の違いほど重要ではありません。
行の順序を気にせず、ID列を主キーとして追加し、日付列にインデックスを追加してクエリを支援する必要がありますか？
ビンゴ：これは、物理データベースの設計と論理データベースの設計の違いです。プログラマーは最初は物理データベースの設計について多くのことを心配する必要がありますが、データベースのサイズがたとえば100 GB未満であれば、いわば論理設計をポストで修正できます。初心者のためにそこにIDフィールドを配置し、その上にクラスター化し、数か月間稼働した後、インデックスの設計を再検討してパフォーマンスを最大化します。
とは言っても、この種の意思決定を経験すると、最初からインデックスを推測できるようになります。それでも、最初は通常、インデックスの設計についてはあまり考慮していません。ユーザーは、私が予想していた方法でデータを照会することはありません。