MongoDB インデックスの詳細説明-03

MongoDB インデックス

インデックスは、データを迅速にクエリするために使用されるデータ構造です。B+Tree は、 一般的に使用されるデータベース インデックス データ構造です。

MongoDB は B+Tree をインデックスとして使用し 、インデックスはコレクションに作成されます。MongoDB はインデックス クエリを使用しません

照会では、まずすべての文書をスキャンしてから、適格な文書を照合します。インデックスを使用してドキュメントを検索するクエリ。

インデックスを使用すると、クエリの効率が大幅に向上します。

指数の分類

インデックスに含まれるフィールドの数に応じて、単一キー インデックスと複合インデックス (または複合インデックス) に分けることができます。

インデックス フィールドの種類に応じて、主キー インデックスと非主キー インデックスに分けることができます。

インデックス ノードと物理レコードの対応により、クラスター化インデックスと非クラスター化インデックスに分類できます。

クラスター化インデックスは、インデックス ノードにはデータ レコードが直接含まれ、後者にはデータ レコードへのポインターのみが含まれることを意味します。

レコードポインタ。

インデックスのさまざまな特性に応じて、一意のインデックス、スパースインデックス、テキストインデックス、地理空間インデックスなどに分類できます。

ほとんどのデータベースと同様に、MongoDB は、単一キー インデックス、複合インデックス、一意のインデックスなどの一般的に使用される構造を含む、さまざまな豊富なインデックス タイプをサポートしています。柔軟なドキュメント タイプを使用しているため、ネストされたフィールドと配列のインデックス作成もサポートされています。適切なインデックスを構築することで、データの検索速度を大幅に向上させることができます。一部の特殊なアプリケーション シナリオでは、MongoDB は地理空間インデックス、テキスト検索インデックス、TTL インデックスなどのさまざまな機能もサポートします。

インデックス設計の原則

1. 原則として、各クエリは対応するインデックスを作成する必要があります。

2. 単一インデックスの設計では、できるだけ多くのクエリを満たすことを考慮する必要があります。

3. インデックスフィールドの選択と順序では、クエリのカバレッジと選択性を考慮する必要があります。

4. 頻繁に更新されるフィールドにインデックスを作成する場合は注意してください

5. 配列インデックスの場合、将来の要素の数を慎重に考慮する必要があります

6. 超長い文字列型フィールドでは注意してインデックスを使用する

7. 同時更新が多い場合、単一のコレクションにあまりにも多くのインデックスを作成することはお勧めできません。

インデックス操作

インデックスを作成する

インデックス作成の構文形式

db.collection.createIndex(keys, options)

Key 値は作成するインデックス フィールドです。1 は昇順でインデックスを作成し、-1 は降順でインデックスを作成します。

オプションのパラメータのリストは次のとおりです。

パラメータ_	種類_	説明_
2	ブール値	インデックス構築プロセスは他のデータベース操作をブロックします。また、バックグラウンドでインデックスを作成するように指定できます 。つまり、オプションの     パラメーター。  「背景」のデフォルトは false です。
ユニークな	ブール値	作成されたインデックスが一意であるかどうか。一意のインデックスを作成するには true を指定します。デフォルト値はfalseです。
名前_	弦	インデックスの名前。指定しない場合、MongoDB はインデックスの フィールド名と並べ替え順序を連結してインデックス名を生成します。
dr opDups	ブール値	バージョン 3.0 以降は非推奨に。一意のインデックスを作成するときに重複レコードを削除するかどうか。  一意のインデックスを作成する場合はtrueを指定します。デフォルト値は false です。
まばらな	ブール値	ドキュメント内に存在しないフィールド データのインデックス作成は有効ではありません。このパラメータには特別な注意が必要です。true に設定すると、対応するフィールドを含まないドキュメントはインデックス フィールドでクエリされなくなります。デフォルト値は false です。
秒後に期限切れになる	私は整数	値を秒単位で 指定してTTL 設定を完了し、コレクションの有効期間を設定します。
v	インデックスバージョン_	インデックスのバージョン番号。デフォルトのインデックスのバージョンは、インデックスの作成時に mongod が実行されていたバージョンによって異なります。
体重_	実行します	インデックスの重み値。値は1 ～ 99,999 で、他のインデックス フィールドと比較したこのインデックス のスコアの重みを示します。
デフォルト言語	弦	テキストインデックス、このパラメータはストップワードのリスト とステミングとトークン化のルールを決定します 。デフォルトでは英語
言語_オーバーライド	弦	テキストインデックスの場合、このパラメータはドキュメントに含まれるフィールド名、言語を指定します。

# 创建索引后台执行
 db.values.createIndex({open: 1, close: 1}, {background: true})
 # 创建唯一索引
 db.values.createIndex({title:1},{unique:true})

インデックスを表示する

#查看索引信息
 db.books.getIndexes()
#查看索引键
 db.books.getIndexKeys()

インデックススペースの使用状況を表示する

db.collection.totalIndexSize([is_detail])

is_detail: オプションのパラメータ。0 または false 以外のデータが渡された場合、コレクション内の各インデックスのサイズと合計サイズが表示されます。0 または false が渡された場合、コレクション内のすべてのインデックスの合計サイズのみが表示されます。デフォルト値は false です。

インデックスの削除

 

#删除集合指定索引
 db.col.dropIndex("索引名称")
 #删除集合所有索引 不能删除主键索引
 db.col.dropIndexes()

インデックスタイプ

単一キーインデックス

特定のフィールドにインデックスを作成する mongoDB は ID に一意の単一キー インデックスを作成するため、よく使用されます。

クエリする ID。このインデックスは、インデックス フィールドの完全一致、並べ替え、および範囲検索に使用されます。

db.books.createIndex({title:1})

 

埋め込みドキュメントフィールドにインデックスを作成します。

複合インデックス 

複合インデックスは複数のフィールドで構成されるインデックスであり、そのプロパティは単一フィールド インデックスと似ています。しかし、違いは コンポジットケーブルです。

参照内のフィールドの順序とフィールドの昇順と降順はクエリのパフォーマンスに直接影響するため 、複合インデックスを設計する際には考慮する必要があります。

さまざまなクエリ シナリオを検討してください。

db.books.createIndex({type:1,favCount:1})

 

マルチキーインデックス

 

配列のプロパティにインデックスを作成します。 この配列の任意の値をクエリすると、このドキュメント、つまり複数のインデックスが検索されます。

同じドキュメントへのエントリまたはキーと値の参照

作成：  

db.inventory.createIndex( { ratings: 1 } )

知らせ：  

マルチキー インデックスは、 複数のフィールドを組み合わせた複合インデックスと混同されやすいのに対し、マルチキー インデックスは

フィールド上にマルチキー（マルチキー）が表示されます 。基本的に、マルチキー インデックスは複合フィールドにも表示できます。

MongoDB は複合インデックス内の複数の配列フィールドをサポートしていません

地理空間インデックス

モバイル インターネットの時代では、位置ベースの検索 (LBS) 機能はすべてのアプリケーション システムのほぼ標準構成になっています。MongoDB は地理空間検索に非常に便利な機能を提供します。 地理空間インデックス (2dsphereindex) は、位置検索を実現するために特別に使用される特別なインデックスです。 事例: MongoDB は「近くのビジネスのクエリ」をどのように実装していますか? 販売者のデータ モデルが次のとおりであると仮定します。

 

db.restaurant.insert({
    restaurantId: 0,
    restaurantName: "兰州牛肉面",
    location: {
        type: "Point",
        coordinates: [73.97, 40.77]
    }
})

2dsphere インデックスを作成する

db.restaurant.createIndex({location : "2dsphere"})

全文索引 (テキスト索引)

MongoDBは全文検索機能をサポートしており、テキストインデックスを構築することで簡単な単語分割検索を実現できます。

db.reviews.createIndex( { comments: "text" } )

$text 演算子は、テキスト インデックスを使用してコレクションに対してテキスト検索を実行できます。 $text は、スペースと句読点を区切り文字として使用して検索文字列を分割し、検索文字列内のすべての単語分割結果に対して論理 OR 演算を実行します。

フルテキスト インデックスを使用すると、高速テキスト検索のニーズを解決できます。たとえば、ブログ記事のコレクションがあり、ブログのコンテンツに基づいて迅速に検索する必要がある場合、ブログ コンテンツに対してテキスト インデックスを確立できます。

db.stores.insert([{
    _id: 1,
    name: "Java Hut",
    description: "Coffee and cakes"
},
{
    _id: 2,
    name: "Burger Buns",
    description: "Gourmet hamburgers"
},
{
    _id: 3,
    name: "Coffee Shop",
    description: "Just coffee"
},
{
    _id: 4,
    name: "Clothes Clothes Clothes",
    description: "Discount clothing"
},
{
    _id: 5,
    name: "Java Shopping",
    description: "Indonesian goods"
}])

名前と説明の全文インデックスを作成する

db.stores.createIndex({name: "text", description: "text"})

 

 

$text 演算子を使用して、リスト「coffee」、「shop」、「java」のいずれかの単語を含むデータ内のすべての店舗を検索します。

db.stores.find({$text: {$search: "java coffee shop"}})

MongoDBのテキストインデックス機能には多くの制限があり、中国語単語分割の機能は公式では提供されていないため 、この機能は

適用シナリオは非常に限られています。

ハッシュインデックス (ハッシュインデックス)

従来の B ツリー インデックスとは異なり、ハッシュ インデックスはハッシュ関数を使用してインデックスを作成します。 インデックス付きフィールドの完全一致、

ただし、範囲クエリやマルチキー ハッシュはサポートされていません 。ハッシュ インデックスのエントリは均等に分散されており、これは断片化されたコレクションでは非常に重要です。

できます

 

 db.users.createIndex({username : 'hashed'})

ワイルドカードインデックス

MongoDB のドキュメント モードは動的に変化し、いくつかの予測不可能なフィールドにワイルドカード インデックスを構築することができます。

これによりクエリが高速化されます

db.products.insert([{
    "product_name": "Spy Coat",
    "product_attributes": {
        "material": ["Tweed", "Wool", "Leather"],
        "size": {
            "length": 72,
            "units": "inches"
        }
    }
},
{
    "product_name": "Spy Pen",
    "product_attributes": {
        "colors": ["Blue", "Black"],
        "secret_feature": {
            "name": "laser",
            "power": "1000",
            "units": "watts",
        }
    }
},
{
    "product_name": "Spy Book"
}])

db.products.createIndex( { "product_attributes.$**" : 1 } )

ワイルドカード インデックスは、単一フィールド クエリの product_attributes またはその埋め込みフィールドをサポートできます。

db.products.find( { "product_attributes.size.length" : { $gt : 60 } } )
db.products.find( { "product_attributes.material" : "Leather" } )
db.products.find( { "product_attributes.secret_feature.name" : "laser" })

 

 考慮事項: ワイルドカード インデックスはインデックス タイプまたはプロパティと互換性がありません。

ワイルドカード インデックスはスパースであり、空のフィールドにインデックスを付けません。したがって、 ワイルドカード インデックスはクエリ フィールドが存在しないドキュメントをサポートできません。

 

#通配符索引不能支持以下查询
db.products.find({
    "product_attributes": {
        $exists: false
    }
}) 
db.products.aggregate([{
    $match: {
        "product_attributes": {
            $exists: false
        }
    }
}])

ワイルドカード インデックスは、ドキュメント/配列自体ではなく、ドキュメントまたは配列のコンテンツのエントリを生成します。したがって、 ワイルドカード インデックスは、ドキュメント/配列の正確な等価一致をサポートできません。 ワイルドカード インデックスは、クエリ フィールドが空のドキュメント {} と等しい場合をサポートできます。

#通配符索引不能支持以下查询:
 db.products.find({ "product_attributes.colors" : [ "Blue", "Black" ] } )

 db.products.aggregate([{
 $match : { "product_attributes.colors" : [ "Blue", "Black" ] }
 }])

インデックス属性

一意のインデックス

現実のシナリオでは、一意性は非常に一般的なインデックス制約要件であり、データ レコードが繰り返されると多くの処理上の問題が発生します。

注文番号やユーザーのログイン名などのトラブル 一意のインデックスを確立することで、コレクション内の文書の参照を保証できます。

特定のフィールドには一意の値があります。

一意のインデックスはドキュメント内の欠落フィールドを null 値に置き換える ため、複数のドキュメントは許可されません

ファイルにインデックスフィールドが欠落している場合。

シャーディングされたコレクションの場合、一意性制約はシャーディング ルールと一致する必要があります。 言い換えれば、グローバルな一意性を保証するために、

一意性のため、シャード キーは一意のインデックスのプレフィックス フィールドとして使用する必要があります。

部分インデックス

部分インデックスは、指定されたフィルター式を満たすドキュメントのみにインデックスを付けます。 ドキュメントのコレクションに含まれることによって

サブセットにはインデックスが付けられ、 部分インデックスではストレージ要件が低くなり、インデックスの作成とメンテナンスにかかるパフォーマンス コストが低くなります。 3.2 新しい

バージョン関数

部分インデックスは、スパース インデックス機能のスーパーセットを提供するため、スパース インデックスよりも優先される必要があります。

db.restaurants.createIndex(
 { cuisine: 1, name: 1 },
 { partialFilterExpression: { rating: { $gt: 5 } } }
 )

PartialFilterExpression オプションは、フィルタ基準を指定するドキュメントを受け入れます。

等価式 (例: field: value、または $eq 演算子の使用)

$exists: true

$gt、$gte、$lt、$lte

$type

トップレベルの $and

​​​​​​​# 符合条件，使用索引
 db.restaurants.find( { cuisine: "Italian", rating: { $gte: 8 } } )
 # 不符合条件，不能使用索引
 db.restaurants.find( { cuisine: "Italian" } )

一意制約と部分インデックスの使用を組み合わせると、一意制約が無効になります。

注: PartialFilterExpressionと一意制約の両方が 指定されている場合 、一意制約はフィルタを満たす場合にのみ適用されます。

式のドキュメント。 一意制約を持つ部分インデックスは、ドキュメントがフィルター条件を満たさない場合、挿入を妨げません。

一意制約を満たすドキュメント。

スパースインデックス

インデックスのスパース プロパティにより、 インデックスにはインデックス付きフィールドを持つドキュメントのエントリのみが含まれ、インデックス付きフィールドがないインデックスはスキップされます。

ドキュメンテーション。

機能: 既存のフィールドを持つドキュメントのみにインデックスを付けます (フィールド値が nullのドキュメントを含む )

#不索引不包含xmpp_id字段的文档
db.addresses.createIndex( { "xmpp_id": 1 }, { sparse: true } )

スパース インデックスによってクエリおよび並べ替え操作の不完全な結果セットが生成される場合、 hint() で明示的にインデックスが指定されない限り、MongoDB はインデックスを使用しません。

スパースかつ一意のインデックスを 使用すると、コレクション内のドキュメントに重複したフィールド値が含まれることはなくなりますが、インデックス付きフィールドを含まないドキュメントの挿入は可能になります。

TTLインデックス

一般的なアプリケーション システムでは、すべてのデータを永続的に保存する必要はありません。たとえば、一部のシステム イベント、ユーザー メッセージなど、

これらのデータは時間の経過とともに重要性が低くなります。さらに重要なのは、これらの大量の履歴データを保存するには、

コストがかかるため、 古くなって使用されなくなったデータは通常、プロジェクト内で古くなります。

通常の慣行は次のとおりです。

解決策 1: 各データのタイムスタンプを記録し、アプリケーション側でタイマーを起動し、タイムスタンプに従って期限切れのデータを定期的に削除する

によると。

解決策 2: データを日付ごとにテーブルに分割し、同じ日のデータを同じテーブルにアーカイブし、期限切れのデータを削除するためにもタイマーを使用します

水面。

データのエージングのために、MongoDB はより便利な方法である TTL (

Time To Live）索引。 TTL

インデックスは日付型のフィールドで宣言する必要があります。TTL インデックスは特別な単一フィールド インデックスです 。MongoDB では次のことができます。

これを使用して、一定の時間または特定の時刻が経過した後にコレクションからドキュメントを自動的に削除します。

db.log_events.insertOne( {
 "createdAt": new Date(),
 "logEvent": 2,
 "logMessage": "Success!"
 } )

db.log_events.createIndex( { "createdAt": 1 }, { expireAfterSeconds: 20 })

 最終的にはクリーンアップされ、データはクエリされませんでした

制約を使用する

TTL インデックスは実際に開発の作業負荷を軽減し、データベースの自動クリーニングにより効率と信頼性が向上します。

ただし、TTL インデックスを使用する場合は、次の制限に注意する必要があります。

TTL インデックスは 1 つのフィールドのみをサポートでき、それは非 _id フィールドである必要があります。 TTL インデックスは、上限付きコレクションでは使用できません。

TTL インデックスはデータのタイムリーなエージングを保証できません 。MongoDB はバックグラウンドで TTLMonitor タイマーを渡します。

古いデータをクリーンアップする場合、デフォルトの間隔は 1 分です。もちろん、データベースの負荷が高すぎる場合は、

TTL の動作はさらに影響を受けます。

TTL インデックスはデータ クリーニングに削除コマンドのみを使用しますが、これはあまり効率的ではありません。 なぜなら

この TTL モニターは、動作中にシステムの CPU とディスクに一定の圧力を引き起こします。 それに対して、日常は、

分割払いテーブルの形で運用する方が効率的です。

ログストレージ:

日付テーブル

固定セット

TTLインデックス

挿入: writeConcern:{w:0}

インデックスの使用に関する推奨事項

1. 各クエリに適切なインデックスを構築する

これは、数千万 (ドキュメント数) を超えるなど、大量のデータを含むコレクション用です。ない場合

MongoDB のインデックス作成では、すべてのドキュメントをディスクからメモリに読み取る必要があるため、MongoDB サーバーに比較的大きな影響を与えます。

負荷が高く、他のリクエストの実行に影響を与えます。

2. 適切な複合インデックスを作成し、クロスインデックスに依存しない

クエリで複数のフィールドを使用する場合、MongoDB にはクロス インデックスとマルチプルという 2 つのインデックス作成手法が使用できます。

複合インデックス。 クロス インデックスは、フィールドごとに単一フィールド インデックスを作成し 、 クエリ実行中に 対応する、クエリ結果を取得します。 現在、相互参照のトリガー率は低いため、

複数のフィールドをクエリする場合は、インデックスを正常に使用できるように複合インデックスを使用することをお勧めします。

3. 複合インデックスフィールドの順序: 一致条件が最初、範囲条件が後 (等価性が最初、範囲が後)

複合インデックスを作成する場合、条件が一致と範囲に分かれている場合は、一致条件 (スポーツ: "マラソン") を複合インデックスの前に置く必要があります。

範囲条件 (年齢: <30) フィールドは複合インデックスの後に配置する必要があります。

4. 可能な限りカバードインデックスを使用する

必須フィールドのみを返し、同時にカバーインデックスを使用してパフォーマンスを向上させることをお勧めします。

5. インデックス作成はバックグラウンドで実行する必要があります

コレクションにインデックスを作成する場合、コレクションが配置されているデータベースは他の読み取りおよび書き込み操作を受け付けません。 大量のデータを含むコレクションのインデックスを構築するには、バックグラウンド実行オプション {background: true} を使用することをお勧めします。

6. 長すぎる配列インデックスの設計を避ける

配列インデックスは複数の値を持つため、保存するためにより多くのスペースが必要です。インデックス付き配列の長さが特に長い場合、または配列

インデックスが制御されずに増大すると、インデックス領域が急激に拡大する可能性があります。

詳細な実行計画を説明する

通常、次の点に注意する必要があります。

クエリがインデックスを使用するかどうか

インデックスによってスキャンされるレコードの数は減りますか?

非効率的なメモリの順序付けはありますか

MongoDB は 、指定されたクエリ モデル (クエリモデル) の実行計画を評価し、実際の状況に応じて調整し、クエリ効率を向上させるのに役立つExplainコマンド を提供します。

Explain() メソッドの形式は次のとおりです 。

db.collection.find().explain(<verbose>)

スキーマ名	説明
クエリプランナー_	実行プランの詳細 (クエリ プラン、コレクション情報、クエリ条件、最適な実行プラン、クエリ モード、MongoDB サービス情報など)。

実行駅	最適な実行計画および拒否された計画の実行状況などの情報
すべての計画の実行	最適な実行計画を選択して実行し、最適な実行計画と他の実行計画の実行を

クエリプランナー

# 未创建title的索引
db.books.find({title:"book‐1"}).explain("queryPlanner")

フィールド名	説明
計画ナーバージョン	実行計画のバージョン
名前空間	クエリのコレクション
ndexFilterSet内	インデックスを使用するかどうか
解析された質問クエリ	クエリ条件

勝利計画	最良の実行計画
たげ_	クエリ方法
フィルター	フィルター条件
方向_	クエリの順序
拒否された計画	拒否された実行計画
サーバー情報	mongodbサーバー情報

 実行統計

ExecutionStats モードの戻り情報には、queryPlanner モードのすべてのフィールドが含まれます。

最適な実行計画の実行

#创建索引
db.books.createIndex({title:1})
 db.books.find({title:"book‐1"}).explain("executionStats")

{
	"createdCollectionAutomatically" : true,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
> db.books.find({title:"book‐1"}).explain("executionStats")
{
	"queryPlanner" : {
		"plannerVersion" : 1,
		"namespace" : "restaurant.books",
		"indexFilterSet" : false,
		"parsedQuery" : {
			"title" : {
				"$eq" : "book‐1"
			}
		},
		"winningPlan" : {
			"stage" : "FETCH",
			"inputStage" : {
				"stage" : "IXSCAN",
				"keyPattern" : {
					"title" : 1
				},
				"indexName" : "title_1",
				"isMultiKey" : false,
				"multiKeyPaths" : {
					"title" : [ ]
				},
				"isUnique" : false,
				"isSparse" : false,
				"isPartial" : false,
				"indexVersion" : 2,
				"direction" : "forward",
				"indexBounds" : {
					"title" : [
						"[\"book‐1\", \"book‐1\"]"
					]
				}
			}
		},
		"rejectedPlans" : [ ]
	},
	"executionStats" : {
		"executionSuccess" : true,
		"nReturned" : 0,
		"executionTimeMillis" : 0,
		"totalKeysExamined" : 0,
		"totalDocsExamined" : 0,
		"executionStages" : {
			"stage" : "FETCH",
			"nReturned" : 0,
			"executionTimeMillisEstimate" : 0,
			"works" : 1,
			"advanced" : 0,
			"needTime" : 0,
			"needYield" : 0,
			"saveState" : 0,
			"restoreState" : 0,
			"isEOF" : 1,
			"docsExamined" : 0,
			"alreadyHasObj" : 0,
			"inputStage" : {
				"stage" : "IXSCAN",
				"nReturned" : 0,
				"executionTimeMillisEstimate" : 0,
				"works" : 1,
				"advanced" : 0,
				"needTime" : 0,
				"needYield" : 0,
				"saveState" : 0,
				"restoreState" : 0,
				"isEOF" : 1,
				"keyPattern" : {
					"title" : 1
				},
				"indexName" : "title_1",
				"isMultiKey" : false,
				"multiKeyPaths" : {
					"title" : [ ]
				},
				"isUnique" : false,
				"isSparse" : false,
				"isPartial" : false,
				"indexVersion" : 2,
				"direction" : "forward",
				"indexBounds" : {
					"title" : [
						"[\"book‐1\", \"book‐1\"]"
					]
				},
				"keysExamined" : 0,
				"seeks" : 1,
				"dupsTested" : 0,
				"dupsDropped" : 0
			}
		}
	},
	"serverInfo" : {
		"host" : "192.168.30.130",
		"port" : 27017,
		"version" : "4.4.9",
		"gitVersion" : "b4048e19814bfebac717cf5a880076aa69aba481"
	},
	"ok" : 1
}

フィールド名	説明
勝利計画。入力ステージ	子ステージを記述し 、その親ステージにドキュメント キーと インデックスキーを提供するために使用されます。
優勝プラン。inputStage 。ステージ	サブクエリメソッド
優勝プラン。inputStage.keyPattern	スキャンされたインデックスの内容
優勝プラン。inputStage.indexName	インデックス名
優勝プラン。inputStage.isMultiKey	マルチキーかどうか。インデックスが配列に構築されている 場合はtrue になります
実行統計。実行成功	実行が成功したかどうか
実行統計。n返品されました	返された番号
実行統計。実行時間ミリス	このステートメントの実行時間
executionStats.executionStages.executionTim eMillisEstimate	检索文档获取数据的时间
executionStats.executionStages.inputStage.ex ecutionTimeMillisEstimate	扫描获取数据的时间
executionStats.totalKeysExamined	索引扫描次数
executionStats.totalDocsExamined	文档扫描次数
executionStats.executionStages.isEOF	是否到达 steam 结尾，  1 或者 true 代表已到达结 尾
executionStats.executionStages.works	工作单元数 ，一个查询会分解成小的工作单元
executionStats.executionStages.advanced	优先返回的结果数
executionStats.executionStages.docsExamine	文档检查数

allPlansExecution返回的信息包含 executionStats 模式的内容，且包含

allPlansExecution:[]块

stage状态

状态	描述
COLLSCAN	全表扫描
IXSCAN	索引扫描
FETCH	根据索引检索指定文档
SHARD_MERGE	将各个分片返回数据进行合并
SORT	在内存中进行了排序
LIMIT	使用limit限制返回数
SKIP	使用skip进行跳过
IDHACK	对_id进行查询
SHARDING_FILTER	通过mongos对分片数据进行查询

COUNTSCAN	count不使用Index进行count时的stage返回
COUNT_SCAN	count使用了Index进行count时的stage返回
SUBPLA	未使用到索引的$or查询的stage返回
TEXT	使用全文索引进行查询时候的stage返回
PROJECTION	限定返回字段时候stage的返回

执行计划的返回结果中尽量不要出现以下stage:

COLLSCAN(全表扫描)

SORT(使用sort但是无index)

不合理的SKIP

SUBPLA(未用到index的$or)

COUNTSCAN(不使用index进行count)