0

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

_id:"2lgy_itmep53vy"
uIdHash:"2lgys2yxouhug5xj3ms45mluxw5hsweu"
userTS:1494055844000

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

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

実行してみた

db.product_data.find( {"uIdHash":"2lgys2yxouhug5xj3ms45mluxw5hsweu"}).sort({"userTS":-1}).explain()

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

1

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

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

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

2

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

db.product_data.find( {"uIdHash":"2lgys2yxouhug5xj3ms45mluxw5hsweu"}).sort({"userTS":-1}).limit(10).explain()

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

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

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

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

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

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

2 に答える 2