1つ以上のインデックスを変更する必要がなく、場合によっては制約チェックも実行する必要がない場合は、テーブルを変更する方が速いのは事実ですが、それらのインデックスを追加する必要がある場合も、ほとんど関係ありません。システムの一部だけでなく、実行したいシステムへの完全な変更を検討する必要があります。
明らかに、すでに数百万の行が含まれているテーブルに1つの行を追加する場合、インデックスを削除して再構築するのはばかげています。
ただし、数百万行を追加する完全に空のテーブルがある場合でも、インデックス作成を後回しにするのに時間がかかる可能性があります。
この理由は、このような挿入はダイレクトパスメカニズムで実行するのが最適であり、インデックスのあるテーブルにダイレクトパス挿入を使用すると、インデックスの作成に必要なデータ（データとROWID）を含む一時セグメントが作成されるためです。 ）。これらの一時セグメントがロードしたばかりのテーブルよりもはるかに小さい場合は、スキャンとインデックスの作成も高速になります。
別の方法として、テーブルに5つのインデックスがある場合は、インデックスを作成するために、インデックスをロードした後に5回の全表スキャンを実行することです。
明らかに、ここには巨大な灰色の領域が含まれていますが、次の点でうまく機能しています：
- 質問の権限と一般的な経験則、および
- 実際のテストを実行して、自分のケースの事実を判断します。
編集：
さらなる考慮事項-インデックスが削除されている間にバックアップを実行します。緊急復旧後、システムを復旧させるためにビジネスに息を吹き込んだときに、すべてのインデックスが適切に配置されていることを確認するスクリプトを用意する必要があります。
また、一括読み込み中にインデックスを維持しないことを絶対に決定した場合は、インデックスを削除しないでください。代わりに無効にしてください。これにより、インデックスの存在と定義のメタデータが保持され、より単純な再構築プロセスが可能になります。無効にされたインデックスが再び有効になるため、テーブルを切り捨てて誤ってインデックスを再度有効にしないように注意してください。