[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["# Optimize query performance\n==========================\n\nTo troubleshoot slow queries, use\n[Query Explain](/firestore/mongodb-compatibility/docs/query-explain)\nto obtain the query execution\nplan and the runtime execution profile. The following section describe\nsteps you can take to optimize query performance depending on the execution profile:\n\nLimit the number of results\n---------------------------\n\nUse the records returned field in the execution tree to\nidentify if the query is returning many documents. Consider limiting the number\nof documents returned by using the\n`$limit`clause. This reduces the serialized byte size of the results when returned to\nthe clients over the network. In cases\nwhere the `Limit` node is preceded by a `MajorSort` node, the query engine can\ncoalesce the `Limit` and the `MajorSort` nodes and replaces a full in-memory\nmaterialization and sort with a TopN sort, reducing the memory requirement for\nthe query.\n\nLimit the Result Document Size\n------------------------------\n\nConsider limiting the size of the\ndocument returned by using the\n`$project` clause to avoid fetching\nunnecessary fields. This helps reduce the compute and memory cost of processing\nintermediate results and the serialized byte size of the results when returned\nto the clients over the network. In cases where all fields referenced in the\nquery are covered by a regular index (not multikey), this also allows the query to be\nfully covered by the index scan, avoiding the need to fetch documents from the\nprimary storage.\n\nUse indexes\n-----------\n\nUse the following instructions to set up and optimize indexes.\n\n### Identify if the query is using an index\n\nYou can identify if the query is using an index by checking the leaf nodes in the\nexecution tree. If the leaf node of the execution tree is a\n[TableScan node](/firestore/mongodb-compatibility/docs/query-explain#tablescan),\nthat means the query is not using an index and is scanning documents from primary\nstorage. If an index is being used, the leaf node of the execution tree will\ndisplay the index ID and index fields of the index.\n\n### Identify if the index used can be optimized\n\nAn index is useful for a query if it can reduce the number of\ndocuments that the query engine needs to fetch from primary storage or if its\nfield ordering can deliver the Sort requirement of the query.\n\nIf an index is used for a query, but the query engine is still fetching and\ndiscarding many documents, as identified by a Scan node that returns many\nrecords followed by a\n[Filter node](/firestore/mongodb-compatibility/docs/query-explain-reference#filter)\nthat returns few records, this is a sign that\nthe query predicate satisfied using the index is not selective. To create a more\nsuitable index, see [Create indexes](#create_indexes).\n\nIf a non-multikey index is used for a query, but the query engine is still\nperforming an in-memory reordering of the result set, as identified by a\n[MajorSort node](/firestore/mongodb-compatibility/docs/query-explain-reference#majorsort)\nin the query execution tree, this is a sign that the index used\ncan't be used to deliver the Sort requirement of the query. To create a more\nsuitable index, see the next section.\n\n### Create Indexes\n\nFollow the index management documentation to\n[create indexes](/firestore/mongodb-compatibility/docs/indexing).\nTo ensure your query can use indexes, create regular (not Multikey) indexes\nwith fields in the following order:\n\n1. All fields that will be used in equality operators. To maximize chance of reuse across queries, order fields in decreasing order of occurrence of the fields in equality operators among queries.\n2. All fields that will be sorted on (in the same order).\n3. Fields that will be used in range or inequality operators in decreasing order of query constraint selectivity.\n4. Fields that will be returned as part of a query in the index: including such fields in the index allows the index to cover the query and avoid having to fetch document from the primary storage.\n\nFor queries that involve filtering and sorting array fields, consider creating\nMultikey indexes.\n\n### Use query hint\n\nIf you have created a more suitable index for\nthe query but the query engine is not using that index, you can override\nthe query engine's index preference by using a query hint."]]