MongoDBのドキュメントによると、通常、インデックスを定期的に再構築する必要はありません。
注 ：ストレージに関するアドバイスは、プラグイン可能なストレージエンジンAPI 。以下の私のコメントは、特にMongoDB3.0以前のデフォルトのMMAPストレージエンジンに関連しています。 WiredTigerとその他のストレージエンジンには、データとインデックスのストレージ実装が異なります。
次の場合、MMAPストレージエンジンを使用してインデックスを再構築すると、いくつかの利点があります。
-
インデックスは、データと比較して予想よりも多くのスペースを消費しています。注：比較のためのベースラインを作成するには、履歴データとインデックスサイズを監視する必要があります。
-
古いインデックス形式から新しい形式に移行する必要があります。再インデックスが表示される場合、これはアップグレードノートに記載されています。たとえば、MongoDB 2.0では、インデックスのパフォーマンスが大幅に向上しました そのため、リリースノートには、アップグレード後のv2.0形式への再インデックスの提案が含まれています。同様に、MongoDB2.6では
2dsphereが導入されました。 （v2.0）インデックス デフォルトの動作が異なります（デフォルトではスパース）。既存のインデックスは、インデックスバージョンのアップグレード後に再構築されません。アップグレードするかどうか/いつアップグレードするかの選択はデータベース管理者に任されています。 -
_idを変更しました 単調に増加するキー（ObjectIDなど）からランダムな値へのコレクションのフォーマット。これは少し難解ですが、_idを挿入する場合、bツリーバケットを（50/50ではなく）90/10に分割するインデックス最適化があります。 常に増加しているs（参照： SERVER-983 ）。_idの性質が ■大幅な変更により、インデックスを再作成することで、より効率的なBツリーを構築できる可能性があります。
一般的なBツリーの動作の詳細については、 Wikipedia：Bツリー を参照してください。
インデックスの使用状況の視覚化
インデックスの内部をもう少し詳しく知りたい場合は、試してみることができる実験的なコマンド/ツールがいくつかあります。これらはMongoDB2.4および2.6のみに限定されると思います：