결과 설명

queryPlanner

explain.queryPlanner 은(는) 쿼리 옵티마이저가 선택한 계획을 자세히 설명합니다.

다음 예제는 클래식 및 슬롯 기반 실행 엔진의 출력을 결합할 수 있으며, 대표적인 것이 아닙니다. 출력은 다를 수 있습니다.

queryPlanner: {
   namespace: <string>,
   indexFilterSet: <boolean>,
   parsedQuery: {
      ...
   },
   planCacheShapeHash: <hexadecimal string>,
   planCacheKey: <hexadecimal string>,
   maxIndexedOrSolutionsReached: <boolean>,
   maxIndexedAndSolutionsReached: <boolean>,
   maxScansToExplodeReached: <boolean>,
   winningPlan: {
     stage: <STAGE1>,
     type: <string>,
     inputStage: {
       stage: <string>,
       ...
     }
   },
   rejectedPlans: [
     <candidate plan1>,
   ]
}

{
   queryPlanner: {
      mongosPlannerVersion: <int>
      winningPlan: {
         stage: <STAGE1>,
         type: <string>,
         shards: [
         {
            shardName: <string>,
            connectionString: <string>,
            serverInfo: {
               ...
            },
            namespace: <string>,
            indexFilterSet: <boolean>,
            parsedQuery: {
               ...
            },
            querySettings: {
               ...
            },
            planCacheShapeHash: <hexadecimal string>,
            planCacheKey: <hexadecimal string>,
            maxIndexedOrSolutionsReached: <boolean>,
            maxIndexedAndSolutionsReached: <boolean>,
            maxScansToExplodeReached: <boolean>,
            winningPlan: {
               stage: <STAGE1>,
               type: <string>,
               inputStage: {
                  stage: <string>,
                  ...
               }
            },
            rejectedPlans: [
              <candidate plan1>,
            ]
         }
         ]
      }
   }
}

explain.queryPlanner

쿼리 옵티마이저에서 선택한 쿼리 계획에 대한 정보를 포함합니다.

explain.queryPlanner.namespace

쿼리가 액세스하는 데이터베이스 및 컬렉션의 네임스페이스 를 <database>.<collection> 형식으로 지정하는 문자열입니다.

explain.queryPlanner.indexFilterSet

MongoDB가 계획 캐시 쿼리 형태에 대해 인덱스 필터를 적용했는지 여부를 지정하는 부울입니다.

explain.queryPlanner.querySettings

쿼리 설정이 설정된 경우 querySettings에는 쿼리 형태에 적용되는 쿼리 설정에 대한 세부 정보가 포함됩니다.

쿼리 설정을 추가하고 explain() 출력과 querySettings를 포함한 예제를 보려면 setQuerySettings를 참조하세요.

버전 8.0에 추가 되었습니다.

explain.queryPlanner.planCacheShapeHash

MongoDB 8.0부터 기존 queryHash 필드 planCacheShapeHash라는 새 필드 에 중복됩니다. 이전 MongoDB 버전을 사용하는 경우 queryHash 필드 만 표시됩니다. 향후 MongoDB 버전에서는 더 이상 사용되지 않는 queryHash 필드 제거 될 예정이며, 대신 planCacheShapeHash 필드 사용해야 합니다.

16진수 문자열. 계획 캐시 쿼리 형태 의 해시로, 계획 캐시 쿼리 형태에만 의존합니다. 동일한 계획 캐시 쿼리 형태 가진 느린 쿼리를 찾으려면 사용합니다.

참고

서로 다른 계획 캐시 쿼리 형태 간의 해시 충돌은 가능하지만 가능성은 낮습니다.

planCacheShapeHash 및 planCacheKey에 대한 자세한 내용은 planCacheShapeHash 및 planCacheKey를 참조하세요.

explain.queryPlanner.planCacheKey

계획 캐시 항목 키의 해시입니다. explain.queryPlanner.planCacheShapeHash와 달리 이 값은 쿼리 형태 와 현재 사용 가능한 인덱스 모두의 함수입니다. 지원 인덱스를 추가하거나 삭제하면 planCacheKey 가 변경될 수 있지만 planCacheShapeHash는 변경되지 않습니다.

planCacheShapeHash 및 planCacheKey에 대한 자세한 내용은 planCacheShapeHash 및 planCacheKey를 참조하세요.

explain.queryPlanner.optimizationTimeMillis

쿼리 최적화에 소요된 시간(밀리초)입니다. 내부 $lookup 쿼리를 최적화하는 시간은 포함되지 않습니다.

explain.queryPlanner.optimizedPipeline

전체 집계 파이프라인 작업이 최적화되고 대신 쿼리 계획 실행 단계 트리에 의해 이행되었음을 나타내는 부울입니다.

예를 들어, 다음 집계 작업은 집계 파이프라인을 사용하지 않고 쿼리 계획 실행 트리에서 수행할 수 있습니다.

db.example.aggregate([ { $match: { someFlag: true } } ] )

이 필드는 값이 true인 경우에만 표시되며 집계 파이프라인 작업에 대한 설명에만 적용됩니다. true인 경우 파이프라인이 최적화되었기 때문에 집계 단계 정보가 출력에 표시되지 않습니다.

explain.queryPlanner.winningPlan

쿼리 옵티마이저에서 선택한 계획이 포함된 문서입니다.

explain.queryPlanner.winningPlan.stage

단계의 이름을 나타내는 문자열입니다. 각 단계에는 해당 유형에 특정한 정보가 포함되어 있습니다( 예시: IXSCAN 에는 인덱스 바운드 포함됨). 하위 단계가 있는 단계에는 inputStage 또는 inputStages 필드 있습니다.

작업에서 클래식 쿼리 실행 엔진 사용할 때 표시됩니다.

explain.queryPlanner.winningPlan.type

stage 이(가) "EOF"(으)로 설정하다 경우 type 은(는) EOF 단계의 이유를 나타내는 문자열입니다.

• "nonExistentNamespace": 쿼리 네임스페이스 존재하지 않습니다.

• "predicateEvalsToFalse": 표현식 단순화를 통해 쿼리 와 일치하는 문서가 없는 것으로 확인되었습니다.

explain.queryPlanner.winningPlan.inputStage

상위 단계에 문서 또는 인덱스 키를 제공하는 하위 단계를 설명하는 문서입니다. 부모가 정확히 한 명의 자식을 가진 경우 표시됩니다.

explain.queryPlanner.winningPlan.inputStages

하위 단계를 설명하는 문서 배열입니다. 하위 단계는 상위 단계에 문서 또는 인덱스 키를 제공합니다. $or 표현식과 같이 부모가 여러 개의 자식 노드를 가질 때 표시됩니다.

작업에서 클래식 쿼리 실행 엔진 사용할 때 표시됩니다.

explain.queryPlanner.winningPlan.isCached

winPlan이 계획 캐시 에 있는지 여부를 나타내는 부울입니다.

이 필드 true(으)로 설정하다 있는 계획(성공 또는 거부됨)은 최대 1개입니다. 캐시된 계획이 없는 경우 모든 계획에 대해 필드 false 입니다.

explain.queryPlanner.winningPlan.queryPlan

쿼리 옵티마이저 저가 선택한 계획을 단계 트리로 표시하여 문서화합니다.

쿼리 슬롯 기반 실행 쿼리 엔진사용할 때 표시됩니다.

버전 5.1에 추가되었습니다.

explain.queryPlanner.winningPlan.queryPlan.stage

단계의 이름을 나타내는 문자열입니다.

각 단계에는 해당 유형에 대한 정보가 포함되어 있습니다. 예시 를 들어, IXSCAN 에는 인덱스 바운드 포함됩니다.

explain.queryPlanner.winningPlan.queryPlan.type

stage 이(가) "EOF"(으)로 설정하다 경우 type 은(는) EOF 단계의 이유를 나타내는 문자열입니다.

• "nonExistentNamespace": 쿼리 네임스페이스 존재하지 않음을 나타냅니다.

• "predicateEvalsToFalse": 표현식 단순화로 인해 쿼리 어떤 문서와도 일치하지 않는다고 판단됨을 나타냅니다.

explain.queryPlanner.winningPlan.queryPlan.planNodeId

실행 계획의 각 단계를 식별하는 고유한 정수 필드입니다. 필드는 explain 결과의 모든 단계에 포함되어 있습니다.

버전 5.1에 추가되었습니다.

explain.queryPlanner.winningPlan.queryPlan.inputStage

explain.queryPlanner.winningPlan.inputStage를 참조하세요.

explain.queryPlanner.winningPlan.slotBasedPlan

슬롯 기반 쿼리 실행 계획 트리 및 단계에 대한 정보가 포함된 문서입니다. MongoDB에서 내부 용도로 사용합니다.

버전 5.1에 추가되었습니다.

explain.queryPlanner.winningPlan.slotBasedPlan.stages

슬롯 기반 쿼리 실행 계획의 각 단계에 대한 정보, 실행 순서, 작업 및 슬롯 할당을 포함하는 문자열입니다. MongoDB의 내부 용도로 사용됩니다.

MongoDB 8.0부터 쿼리가 블록 처리를 사용하는 경우 stages 출력에 block_to_row 및 ts_bucket_to_cellblock이 나타납니다.

버전 8.0에서 변경되었습니다.

explain.queryPlanner.rejectedPlans

쿼리 최적화 프로그램에서 고려하고 거부한 후보 계획의 배열입니다. 다른 후보 계획이 없는 경우 배열은 비어 있을 수 있습니다.

거부된 계획에는 explain.queryPlanner.winningPlan 과 동일한 필드가 있습니다.

MongoDB 8.0 부터 거부된 쿼리 계획에는 쿼리 의 find 부분만 포함됩니다. 이전 버전에서는 거부된 계획에 $group 와 같은 집계 단계가 포함될 수 있습니다. 쿼리 플래너가 성공적인 계획을 선택하는 데 이러한 집계 단계를 사용하지 않으므로 rejectedPlans 필드 에는 가장 적합한 계획을 선택하는 데 사용된 쿼리 부분만 포함됩니다.

executionStats

반환된 explain.executionStats 정보에는 성공적인 계획의 실행 방법이 자세히 설명되어 있습니다. 결과에 executionStats를 포함하려면 다음 중 하나에서 explain을 실행해야 합니다.

• executionStats 또는

• allPlansExecution 세부 정보 표시 모드입니다. allPlansExecution 모드를 사용하여 계획 선택 중에 캡처한 부분 실행 데이터를 포함할 수 있습니다.

이러한 예시는 MongoDB의 클래식 및 슬롯 기반 실행 엔진의 출력 구조를 결합할 수 있습니다. 대표성을 갖기 위한 것이 아닙니다. 실제 출력은 크게 다를 수 있습니다.

executionStats: {
   executionSuccess: <boolean>,
   nReturned: <int>,
   executionTimeMillis: <int>,
   totalKeysExamined: <int>,
   totalDocsExamined: <int>,
   executionStages: {
      stage: <STAGE1>
      nReturned: <int>,
      executionTimeMillisEstimate: <int>,
      opens: <int>, // Starting in MongoDB 5.1
      closes: <int>, // Starting in MongoDB 5.1
      works: <int>,
      advanced: <int>,
      needTime: <int>,
      needYield: <int>,
      saveState: <int>,
      restoreState: <int>,
      isEOF: <boolean>,
      ...
      inputStage: {
         stage: <STAGE2>,
         nReturned: <int>,
         ...
         numReads: <int>, // Starting in MongoDB 5.1
         ...
         executionTimeMillisEstimate: <int>,
         ...
         spills: <long long>,
         spilledBytes: <long long>,
         spilledRecords: <long long>,
         spilledDataStorageSize: <long long>,
         ...
         inputStage: {
            ...
         }
      }
   },
   allPlansExecution: [
      {
         nReturned: <int>,
         executionTimeMillisEstimate: <int>,
         totalKeysExamined: <int>,
         totalDocsExamined: <int>,
         score: <double>,
         executionStages: {
            stage: <STAGEA>,
            nReturned: <int>,
            executionTimeMillisEstimate: <int>,
            ...
            inputStage: {
               stage: <STAGEB>,
               ...
               inputStage: {
                 ...
               }
            }
         }
      },
      ...
   ]
   operationMetrics: {
      cpuNanos: <int>,
      cursorSeeks: <int>,
      docBytesRead: <int>,
      docBytesWritten: <int>,
      docUnitsRead: <int>,
      docUnitsReturned: <int>,
      docUnitsWritten: <int>,
      idxEntryBytesRead: <int>,
      idxEntryBytesWritten: <int>,
      idxEntryUnitsRead: <int>,
      idxEntryUnitsWritten: <int>,
      totalUnitsWritten: <int>,
      keysSorted: <int>,
      sorterSpills: <int>
   }
}

executionStats: {
   nReturned: <int>,
   executionTimeMillis: <int>,
   totalKeysExamined: <int>,
   totalDocsExamined: <int>,
   executionStages: {
      stage: <STAGE1>
      nReturned: <int>,
      executionTimeMillis: <int>,
      opens: <int>, // Starting in MongoDB 5.1
      closes: <int>, // Starting in MongoDB 5.1
      totalKeysExamined: <int>,
      totalDocsExamined: <int>,
      totalChildMillis: <NumberLong>,
      shards: [
         {
            shardName: <string>,
            executionSuccess: <boolean>,
            executionStages: {
               stage: <STAGE2>,
               nReturned: <int>,
               executionTimeMillisEstimate: <int>,
               ...
               chunkSkips: <int>,
               inputStage: {
                  stage: <STAGE3>,
                  ...
                  numReads: <int>, // Starting in MongoDB 5.1
                  ...
                  spills: <long long>,
                  spilledBytes: <long long>,
                  spilledRecords: <long long>,
                  spilledDataStorageSize: <long long>,
                  ...
                  inputStage: {
                     ...
                  }
               }
            }
         },
         ...
      ]
   }
   allPlansExecution: [
      {
         shardName: <string>,
         allPlans: [
            {
               nReturned: <int>,
               executionTimeMillisEstimate: <int>,
               totalKeysExamined: <int>,
               totalDocsExamined:<int>,
               executionStages: {
                  stage: <STAGEA>,
                  nReturned: <int>,
                  executionTimeMillisEstimate: <int>,
                  ...
                  inputStage: {
                     stage: <STAGEB>,
                     ...
                     inputStage: {
                       ...
                     }
                  }
               }
            },
            ...
         ]
      },
      {
         shardName: <string>,
         allPlans: [
          ...
         ]
      },
      ...
   ]
}

explain.executionStats

우승한 계획에 대해 완료된 쿼리 실행을 설명하는 통계가 포함됩니다. 쓰기 작업의 경우 완료된 쿼리 실행은 수행될 수정을 의미하지만 데이터베이스에 수정 사항을 적용하지는 않습니다.

explain.executionStats.nReturned

성공적인 쿼리 계획이 반환한 문서의 수입니다. nReturned는 이전 버전의 MongoDB에서 cursor.explain()이 반환한 n 필드에 해당합니다.

explain.executionStats.executionTimeMillis

쿼리 계획 선택과 쿼리 실행에 필요한 총 시간(밀리초 단위)입니다. 여기에는 계획 선택 프로세스의 시험 단계를 실행하는 데 걸리는 시간을 포함하지만, 클라이언트로 데이터를 전송하는 데 걸리는 네트워크 시간은 포함하지 않습니다.

explain.executionStats.executionTimeMillis에서 보고한 시간이 반드시 실제 쿼리 시간을 나타내는 것은 아닙니다. 정상 상태 작업 중(쿼리 계획이 캐시된 경우) 또는 cursor.hint()을 cursor.explain()와 함께 사용하는 경우, MongoDB는 계획 선택 프로세스를 우회하여 실제 시간을 단축하므로 explain.executionStats.executionTimeMillis 값이 더 낮아집니다.

explain.executionStats.totalKeysExamined

스캔한 인덱스 항목 수입니다. explain.executionStats.totalKeysExamined는 이전 버전의 MongoDB에서 cursor.explain()이 반환한 nscanned 필드에 해당합니다.

explain.executionStats.totalDocsExamined

쿼리 실행 중에 검토한 문서 수입니다. 문서를 검사하는 일반적인 쿼리 실행 단계는 COLLSCAN 및 FETCH입니다.

참고

explain.executionStats.totalDocsExamined는 반환된 문서 수가 아닌 검토한 총 문서 수를 나타냅니다. 예를 들어, 스테이지에서는 필터를 적용하기 위해 문서를 검토할 수 있습니다. 문서가 필터링된 경우, 해당 문서는 검토가 완료된 것이며 쿼리 집합의 일부로 반환되지 않습니다.

쿼리 실행 중에 문서를 여러 번 검사하는 경우 explain.executionStats.totalDocsExamined는 각 검사 횟수를 계산합니다. 즉, explain.executionStats.totalDocsExamined는 검토한 고유 문서의 총 수를 포함하지 않습니다.

explain.executionStats.executionStages

성공적인 계획의 완료된 실행을 단계 트리로 자세히 설명합니다. 즉, 단계는 하나의 inputStage 또는 여러 개의 inputStages를 가질 수 있습니다.

MongoDB 5.1부터 단계에 다음과 같은 입력 단계를 가질 수 있습니다.

• thenStage

• elseStage

• innerStage

• outerStage

각 단계는 단계와 관련된 실행 정보로 구성됩니다.

explain.executionStats.executionStages.executionTimeMillisEstimate

쿼리 실행에 대한 예상 시간(밀리초)입니다.

explain.executionStats.executionStages.opens

MongoDB 5.1부터 쿼리 실행 중에 단계가 열린 횟수입니다.

explain.executionStats.executionStages.closes

MongoDB 5.1부터 쿼리 실행 중에 단계가 닫힌 횟수입니다.

explain.executionStats.executionStages.works

쿼리 실행 단계에서 수행되는 "작업 단위" 수를 지정합니다. 쿼리 실행은 작업을 작은 단위로 나눕니다. "작업 단위"는 단일 인덱스 키를 검사하거나, 컬렉션에서 단일 문서를 가져오거나, 단일 문서에 프로젝션을 적용하거나, 내부 회계 작업을 수행하는 것으로 구성될 수 있습니다.

이 필드는 작업에서 클래식 쿼리 실행 엔진을 사용한 경우 나타납니다.

explain.executionStats.executionStages.saveState

쿼리 단계에서 처리를 일시 중단하고 현재 실행 상태를 저장한 횟수입니다(예시: 잠금 양보를 위한 준비).

explain.executionStats.executionStages.restoreState

쿼리 단계에서 저장된 실행 상태를 복원한 횟수입니다(예시: 이전에 생성된 잠금을 복구한 후).

explain.executionStats.executionStages.isEOF

실행 단계가 스트림 종료에 도달했는지 여부를 지정합니다.

• true 또는 1이면 실행 단계가 스트림 종료에 도달한 것입니다.

• false 또는 0인 경우 단계에 반환할 결과가 남아있을 수 있습니다. 예를 들어 실행 단계가 쿼리의 입력 단계가 IXSCAN인 LIMIT 단계로 구성된 제한이 있는 쿼리를 가정해 보겠습니다. 쿼리가 지정된 제한보다 많은 값을 반환하는 경우 LIMIT 단계는 isEOF: 1을 보고하지만 기본 IXSCAN 단계는 isEOF: 0을 보고합니다.

explain.executionStats.executionStages.opType

Time Series 컬렉션에 대한 작업에서 작업 유형입니다.

explain.executionStats.executionStages.bucketFilter

Time Series 컬렉션 작업에서 버킷 카탈로그에서 쿼리된 버킷 수를 줄이는 데 사용되는 필터입니다.

explain.executionStats.executionStages.residualFilter

Time Series 컬렉션에 대한 작업에서 버킷 카탈로그를 쿼리 하는 데 사용되는 필터하다 입니다.

explain.executionStats.executionStages.nBucketsUnpacked

Time Series 컬렉션 작업에서 작업을 해결하기 위해 언팩된 버킷 수입니다.

explain.executionStats.executionStages.nMeasurementsDeleted

Time Series 컬렉션에 대한 작업에서 삭제된 문서 수입니다.

explain.executionStats.executionStages.nMeasurementsInserted

Time Series 컬렉션에 대한 작업에서 삽입된 문서 수입니다.

explain.executionStats.executionStages.nMeasurementsMatched

Time Series 컬렉션에 대한 작업에서 일치하는 문서 수입니다.

explain.executionStats.executionStages.nMeasurementsModified

Time Series 컬렉션에 대한 작업에서 수정된 문서 수입니다.

explain.executionStats.executionStages.nMeasurementsUpserted

Time Series 컬렉션에 대한 작업에서 업서트된 문서 수입니다.

explain.executionStats.executionStages.inputStage

각 inputStage는 inputStage.stage의 값에 따라 다른 필드를 가질 수 있습니다. 다음 표에서는 가능한 필드와 해당 필드가 표시될 수 있는 단계에 대해 설명합니다.

각 inputStage는 다른 inputStage를 필드로 가질 수 있습니다. 출력 구조 설명을 참조하세요.

필드	설명	적용 가능한 단계
docsExamined	쿼리 실행 단계에서 스캔되는 문서 수를 지정합니다.	COLLSCAN, FETCH
keysExamined	쿼리 실행 단계에서 인덱스 keysExamined는 인덱스 스캔 프로세스에서 검사되는 내부 및 범위를 벗어난 키의 총 수입니다. 인덱스 스캔이 단일 연속 키 범위로 구성된 경우 인바운드 키만 검사하면 됩니다. 인덱스 경계가 여러 키 범위로 구성된 경우 인덱스 스캔 실행 프로세스에서 범위를 벗어난 키를 검사하여 한 범위의 끝에서 다음 범위의 시작으로 건너뛸 수 있습니다.	IXSCAN
numReads	쿼리 실행 단계에서 검사된 문서 수 또는 검사된 인덱스 키 수입니다. 버전 5.1에 추가되었습니다.	COLLSCAN, IXSCAN
seeks	인덱스 스캔을 완료하기 위해 인덱스 커서를 새 위치로 이동해야 했던 횟수입니다.	IXSCAN
usedDisk	해당 단계가 디스크를 썼는지 여부입니다. 버전 5.3에 추가.	GROUP
spills	단계가 디스크로 유출된 횟수입니다. 버전 8.2에 추가 되었습니다.	GROUP, SORT
spilledBytes	디스크에 기록된 데이터의 총량(바이트)입니다. 버전 8.2에 추가 되었습니다.	GROUP, SORT
spilledRecords	디스크로 유출된 개별 레코드의 총 개수입니다. 버전 8.2에 추가 되었습니다.	GROUP, SORT
spilledDataStorageSize	유출된 데이터가 사용한 총 디스크 공간(바이트)입니다. 버전 8.2에 추가 되었습니다.	GROUP, SORT

explain.executionStats.allPlansExecution

채택된 계획과 거부된 계획 모두에 대해 계획 선택 단계에서 캡처한 부분 실행 정보를 포함합니다. 이 필드는 explain가 allPlansExecution 세부 정보 표시 모드에서 실행되는 경우에만 표시됩니다.

explain.executionStats.operationMetrics

0이 아닌 한 리소스 소비 통계를 포함합니다. 이 필드 explain 가 executionStats 상세도 모드 이상에서 실행되고 profileOperationResourceConsumptionMetrics 가 활성화된 경우에만 표시됩니다.

경고

MongoDB 8.2 이 profileOperationResourceConsumptionMetrics을(를) 제거합니다. 따라서 operationMetrics 에 의존하는 코드는 작동하지 않습니다.

serverInfo

serverInfo: {
   host: <string>,
   port: <int>,
   version: <string>,
   gitVersion: <string>
}

queryPlanner: {
   ...
   winningPlan: {
      stage: <STAGE1>,
      shards: [
         {
            shardName: <string>,
            connectionString: <string>,
            serverInfo: {
               host: <string>,
               port: <int>,
               version: <string>,
               gitVersion: <string>
            },
            ...
         }
         ...
      ]
   }
 },
 serverInfo: {      // serverInfo for mongos
   host: <string>,
   port: <int>,
   version: <string>,
   gitVersion: <string>
 }
 ...