现已推出具有 MongoDB 兼容性的 Firestore 企业版!
了解详情。
盡可能提高查詢效能
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
僅適用於 Cloud Firestore Enterprise 版。
|
如要排解查詢速度緩慢的問題,請使用「查詢說明」取得查詢執行計畫和執行階段執行設定檔。以下各節說明如何根據執行設定檔,採取適當步驟來最佳化查詢效能:
限制結果數量
使用執行樹狀結構中的「傳回的記錄」欄位,判斷查詢是否傳回大量文件。建議使用 $limit
子句限制傳回的文件數量。這樣一來,透過網路傳回用戶端時,結果的序列化位元組大小就會減少。如果 Limit
節點前面有 MajorSort
節點,查詢引擎可以合併 Limit
和 MajorSort
節點,並以 TopN 排序取代完整的記憶體內具體化和排序,進而減少查詢的記憶體需求。
限制結果文件大小
建議使用 $project
子句限制傳回的文件大小,避免擷取不必要的欄位。這有助於減少處理中繼結果的運算和記憶體成本,以及透過網路傳回用戶端時,結果的序列化位元組大小。如果查詢中參照的所有欄位都包含在一般索引 (非多鍵) 中,查詢也可以完全由索引掃描涵蓋,避免從主要儲存空間擷取文件。
使用索引
請按照下列操作說明設定及最佳化索引。
判斷查詢是否使用索引
您可以檢查執行樹狀結構中的葉節點,判斷查詢是否使用索引。如果執行樹狀結構的葉節點是 TableScan 節點,表示查詢並未使用索引,而是掃描主要儲存空間中的文件。如果使用索引,執行樹狀結構的葉節點會顯示索引的索引 ID 和索引欄位。
判斷使用的索引是否可以最佳化
如果索引可以減少查詢引擎需要從主要儲存空間擷取的檔案數量,或者索引的欄位排序可以滿足查詢的排序需求,索引對查詢就很有用。
如果查詢使用索引,但查詢引擎仍會擷取並捨棄大量文件 (如傳回大量記錄的掃描節點,後接傳回少量記錄的篩選節點),表示使用索引滿足的查詢述詞不具選擇性。如要建立更合適的索引,請參閱「建立索引」。
如果查詢使用非多鍵索引,但查詢引擎仍在執行結果集的記憶體內重排序,如查詢執行樹狀結構中的 MajorSort 節點所示,這表示所用索引無法用於提供查詢的排序需求。如要建立更合適的索引,請參閱下一節。
建立索引
請參閱索引管理說明文件,瞭解如何建立索引。為確保查詢可以使用索引,請依下列順序建立一般 (而非 Multikey) 索引:
- 所有將用於等號運算子的欄位。如要盡量在查詢中重複使用欄位,請依查詢中等號運算子內欄位的出現次數,以遞減順序排序欄位。
- 所有要排序的欄位 (順序相同)。
- 將用於範圍或不相等運算子的欄位,依查詢限制選擇性遞減排序。
- 將做為索引查詢一部分傳回的欄位:在索引中加入這類欄位,可讓索引涵蓋查詢內容,避免必須從主要儲存空間擷取文件。
如果查詢涉及篩選及排序陣列欄位,請考慮建立多鍵索引。
使用查詢提示
如果您已為查詢建立更合適的索引,但查詢引擎並未使用該索引,則可以使用查詢提示,覆寫查詢引擎的索引偏好設定。
如要進一步瞭解使用「查詢說明」執行的查詢輸出內容,請參閱查詢執行參考資料。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-29 (世界標準時間)。
[null,null,["上次更新時間: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)."]]