现已推出具有 MongoDB 兼容性的 Firestore 企业版!
了解详情。
优化查询性能
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
仅与 Cloud Firestore 企业版相关。
|
如需排查查询速度缓慢问题,请使用查询解释获取查询执行计划和运行时执行配置文件。以下部分介绍了您可以根据执行配置文件采取哪些步骤来优化查询性能:
限制结果数
使用执行树中的“返回的记录数”字段来确定查询是否返回了大量文档。考虑使用 $limit
子句限制返回的文档数量。这样可以减小通过网络返回给客户端的结果的序列化字节大小。如果 Limit
节点前面是 MajorSort
节点,查询引擎可以合并 Limit
和 MajorSort
节点,并使用 TopN 排序替换完整的内存中具体化和排序,从而降低查询的内存要求。
限制结果文档大小
考虑使用 $project
子句限制返回的文档的大小,以避免提取不必要的字段。这有助于降低处理中间结果的计算和内存成本,以及通过网络返回给客户端的结果的序列化字节大小。如果查询中引用的所有字段都包含在常规索引(而非多键索引)中,则查询也可以完全由索引扫描覆盖,从而避免需要从主存储空间中提取文档。
使用索引
请按照以下说明设置和优化索引。
确定查询是否使用了索引
您可以通过检查执行树中的叶节点来确定查询是否使用了索引。如果执行树的叶节点是 TableScan 节点,则表示查询未使用索引,而是扫描主存储空间中的文档。如果正在使用索引,执行树的叶节点将显示索引的索引 ID 和索引字段。
确定所用索引是否可以优化
如果索引可以减少查询引擎需要从主存储空间中提取的文档数量,或者其字段排序可以满足查询的排序要求,则该索引对查询很有用。
如果查询使用了索引,但查询引擎仍在提取和舍弃许多文档(如通过以下方式识别:一个返回许多记录的扫描节点,后跟一个返回少量记录的过滤节点),则表明使用索引满足的查询谓词不具有选择性。如需创建更合适的索引,请参阅创建索引。
如果查询使用了非多键索引,但查询引擎仍在对结果集执行内存中重新排序(如查询执行树中的 MajorSort 节点所标识的那样),则表明所使用的索引无法满足查询的排序要求。如需创建更合适的索引,请参阅下一部分。
创建索引
按照索引管理文档创建索引。
为确保查询可以使用索引,请按以下顺序创建包含字段的常规(非多键)索引:
- 将用于等式运算符的所有字段。
为了最大限度地提高在不同查询中重复使用索引的机会,请按字段在查询的等值运算符中出现的次数降序排列字段。
- 将用于排序的所有字段(按相同顺序)。
- 将按查询限制条件的严苛程度降序排列的范围或不等式运算符中使用的字段。
- 将作为索引中查询的一部分返回的字段:在索引中包含此类字段可让索引涵盖查询,并避免必须从主存储空间中提取文档。
对于涉及过滤和排序数组字段的查询,请考虑创建多键索引。
使用查询提示
如果您已为查询创建了更合适的索引,但查询引擎未使用该索引,则可以使用查询提示来替换查询引擎的索引偏好设置。
如需详细了解使用“查询解释”执行查询的输出,请参阅查询执行参考文档。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-29。
[null,null,["最后更新时间 (UTC):2025-08-29。"],[],[],null,["\u003cbr /\u003e\n\n\n|--------------------------------------------------------|\n| *Relevant to Cloud Firestore Enterprise edition only.* |\n\n\u003cbr /\u003e\n\nTo troubleshoot slow queries, use\n[Query Explain](/docs/firestore/enterprise/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\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\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\nUse the following instructions to set up and optimize indexes.\n\nIdentify 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](/docs/firestore/enterprise/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\nIdentify 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](/docs/firestore/enterprise/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](/docs/firestore/enterprise/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\nCreate Indexes\n\nFollow the index management documentation to\n[create indexes](/docs/firestore/enterprise/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\nUse 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.\n\nFor more information on the output of a query executed with Query Explain, see [Query execution reference](/docs/firestore/enterprise/query-explain-reference)."]]