느린 쿼리 문제를 해결하려면 Query Explain을 사용하여 쿼리 실행 계획과 런타임 실행 프로필을 가져옵니다. 다음 섹션에서는 실행 프로필에 따라 쿼리 성능을 최적화하기 위해 취할 수 있는 단계를 설명합니다.
결과 수 제한
실행 트리에서 반환된 레코드 필드를 사용하여 쿼리가 많은 문서를 반환하는지 확인합니다. $limit 절을 사용하여 반환되는 문서 수를 제한하는 것이 좋습니다. 이렇게 하면 네트워크를 통해 클라이언트에 반환될 때 결과의 직렬화된 바이트 크기가 줄어듭니다. Limit 노드 앞에 MajorSort 노드가 있는 경우 쿼리 엔진은 Limit 및 MajorSort 노드를 병합하고 전체 인메모리 구체화 및 정렬을 TopN 정렬로 대체하여 쿼리의 메모리 요구사항을 줄일 수 있습니다.
결과 문서 크기 제한
불필요한 필드를 가져오지 않도록 $project 절을 사용하여 반환되는 문서의 크기를 제한하는 것이 좋습니다. 이렇게 하면 중간 결과 처리의 컴퓨팅 및 메모리 비용과 네트워크를 통해 클라이언트에 반환될 때 결과의 직렬화된 바이트 크기를 줄일 수 있습니다. 쿼리에서 참조되는 모든 필드가 일반 색인(멀티 키 아님)으로 처리되는 경우 쿼리가 색인 검색으로 완전히 처리되어 기본 스토리지에서 문서를 가져올 필요가 없습니다.
색인 사용
다음 안내에 따라 색인을 설정하고 최적화하세요.
쿼리에서 색인을 사용하고 있는지 확인
실행 트리의 리프 노드를 확인하여 쿼리에서 색인을 사용하고 있는지 확인할 수 있습니다. 실행 트리의 리프 노드가 TableScan 노드인 경우 쿼리가 색인을 사용하지 않고 기본 스토리지에서 문서를 스캔하고 있음을 의미합니다. 색인이 사용 중인 경우 실행 트리의 리프 노드에 색인의 색인 ID와 색인 필드가 표시됩니다.
사용된 색인을 최적화할 수 있는지 확인
색인은 쿼리 엔진이 기본 스토리지에서 가져와야 하는 문서 수를 줄일 수 있거나 필드 순서가 쿼리의 정렬 요구사항을 충족할 수 있는 경우 쿼리에 유용합니다.
쿼리에 색인이 사용되지만 쿼리 엔진이 여전히 많은 문서를 가져와서 삭제하는 경우(많은 레코드를 반환하는 스캔 노드와 적은 레코드를 반환하는 필터 노드로 식별됨) 색인을 사용하여 충족된 쿼리 조건자가 선택적이지 않다는 신호입니다. 더 적합한 색인을 만들려면 색인 만들기를 참고하세요.
쿼리에 멀티 키가 아닌 색인이 사용되지만 쿼리 엔진이 여전히 쿼리 실행 트리의 MajorSort 노드로 식별되는 결과 집합의 메모리 내 재정렬을 실행하는 경우, 이는 사용된 색인이 쿼리의 정렬 요구사항을 제공하는 데 사용될 수 없다는 신호입니다. 더 적합한 색인을 만들려면 다음 섹션을 참고하세요.
색인 만들기
색인 관리 문서를 따라 색인을 만듭니다.
쿼리에서 색인을 사용할 수 있도록 하려면 다음 순서로 필드가 있는 일반(멀티 키 아님) 색인을 만드세요.
등호 연산자에 사용될 모든 필드입니다.
쿼리 간 재사용 가능성을 극대화하려면 쿼리 간 등호 연산자에서 필드가 발생하는 빈도의 내림차순으로 필드를 정렬합니다.
정렬할 모든 필드(동일한 순서)입니다.
범위 또는 부등호 연산자에 사용될 필드입니다(쿼리 제약 조건 선택성의 내림차순).
색인의 쿼리 일부로 반환될 필드: 색인에 이러한 필드를 포함하면 색인이 쿼리를 처리하고 기본 스토리지에서 문서를 가져오지 않아도 됩니다.
배열 필드의 필터링 및 정렬이 포함된 쿼리의 경우 멀티 키 색인을 만드는 것이 좋습니다.
쿼리 힌트 사용
쿼리에 더 적합한 색인을 만들었지만 쿼리 엔진에서 해당 색인을 사용하지 않는 경우 쿼리 힌트를 사용하여 쿼리 엔진의 색인 환경설정을 재정의할 수 있습니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[],[],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."]]
