私が読んだコメントで
補足として、テーブルのインデックスを削除し、一括挿入操作の後に再作成する方が速い場合があります。
これは本当ですか?どのような状況で?
私が読んだコメントで
補足として、テーブルのインデックスを削除し、一括挿入操作の後に再作成する方が速い場合があります。
これは本当ですか?どのような状況で?
ジョエルと同じように、私はそうであるという声明を繰り返します。彼が言及したシナリオを特定する鍵は、すべてデータの分布と、特定のテーブルにあるインデックスのサイズにあることがわかりました。
私がサポートしていたアプリケーションでは、180 万行の通常の一括インポートを行いました。テーブルには 4 つのインデックスがあり、1 つのインデックスは 11 列で、テーブルには合計 90 列ありました。インデックスを含むインポートが完了するまでに 20 時間以上かかりました。インデックスの削除、挿入、およびインデックスの再作成にかかった時間は、わずか 1 時間 25 分でした。
したがって、これは大きな助けになる可能性がありますが、その多くはデータ、インデックス、およびデータ値の分布に依存します。
はい、そうです。挿入中にテーブルにインデックスがある場合、インデックスを最新の状態に保つために、サーバーは常にテーブルの順序を変更/ページングする必要があります。インデックスを削除すると、それを気にせずに行を追加でき、再作成時にインデックスを一度に構築できます。
もちろん、例外は、インポート データが既にインデックス順になっている場合です。実際、私は現在、この反対の効果が観察されたプロジェクトに取り組んでいることに注意してください。大規模なインポート (メインフレーム システムからの夜間のダンプ) の実行時間を短縮したかったのです。インデックスの削除、データのインポート、再作成を試みました。実際には、インポートが完了するまでの時間が大幅に増加しました。しかし、これは一般的ではありません。特定のシステムについて常に最初にテストする必要があることを示しています。
インデックスを削除して再作成する際に考慮すべきことの 1 つは、データベースの使用量が少ない期間に実行される自動化されたプロセスでのみ実行することです。インデックスが削除されている間は、他のユーザーが同時に実行している可能性のある他のクエリには使用できません。生産時間中にこれを行うと、ユーザーはおそらくタイムアウトについて不平を言い始めます。