問題タブ [mongo-collection]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
62 参照

mongodb - Mongo で複合インデックスを使用する追加の LIMIT ステージが必要なのはなぜですか?

私はMongo 4.2を使用しています(これで立ち往生しています)。次のスキーマを持つドキュメントを含む「product_data」というコレクションがあります:

ケース 1 : これにより、コレクションに次のインデックスがあります。

  1. _id:レギュラー - ユニーク
  2. uIdHash: ハッシュ

実行してみた

これらは結果の段階です。

1

もちろん、mongo のメモリ内の「並べ替え」段階を回避するために、複合インデックスを追加することが理にかなっていることがわかりました。

ケース 2 : 既存のインデックスに別のインデックスを追加しようとしました 3. {uIdHash:1 , userTS:-1}: 通常および複合

私の予想通り、ここで実行した結果は、並べ替え段階で最適化できました。

2



これまでのところ、このクエリの上にページネーションを構築しようとしています。照会するデータを制限する必要があります。したがって、クエリはさらに次のように変換されます

各ケースの結果は次のとおりです。

ケース 1 制限結果: ここに画像の説明を入力

メモリ内の並べ替えは作業が少なく (50 ではなく 36)、期待される数のドキュメントを返します。まあまあ、ステージの根本的な最適化は適切です。

Case 2 Limit Result : ここに画像の説明を入力 驚いたことに、使用中のインデックスと照会されたデータにより、追加の Limit ステージが処理に追加されました!

今疑問に思っていることは以下のとおりです。

  1. すでに 10 個のドキュメントが FETCH ステージから返されているのに、なぜ LIMIT に追加のステージが必要なのですか?
  2. この追加ステージの影響はどのようなものでしょうか? ページネーションが必要な場合、ケース 1 インデックスを使用し、最後の複合インデックスを使用しないでください。