결과 설명
이 페이지의 내용
쿼리 계획에 대한 정보와 쿼리 계획의 실행 통계를 반환하기 위해 MongoDB는 다음과 같은 메서드를 제공합니다.
중요한 설명 결과 필드와 이를 해석하는 방법에 대해 알아보려면 계획 결과 설명 해석을 참조하세요.
중요
explain
은 계획 캐시를 무시합니다. 대신 후보 계획 세트가 생성되고 계획 캐시를 참조하지 않고 후보가 선택됩니다. 또한 explain
은 MongoDB 쿼리 플래너가 성공적인 계획을 캐싱하지 못하도록 합니다.
참고
이 페이지에는 가장 중요한 출력 필드만 표시되며 내부 사용을 위한 필드는 문서화되지 않습니다. 출력에 나열된 필드는 변경될 수 있습니다.
출력 구조 설명
explain
결과는 쿼리 계획을 단계 트리로 표시합니다. 출력 구조는 작업에서 사용하는 쿼리 엔진에 따라 달라질 수 있습니다. 작업은 클래식 쿼리 엔진 또는 슬롯 기반 실행 쿼리 엔진을 사용할 수 있습니다.
두 실행 엔진 간의 출력 구조가 어떻게 다른지 확인하려면 다음 예를 참조하세요.
winningPlan: { stage: <STAGE1>, ... inputStage: { stage: <STAGE2>, ... inputStage: { stage: <STAGE3>, ... } } },
winningPlan: { queryPlan: { stage: <STAGE1>, ... inputStage: { stage: <STAGE2>, ... inputStage: { stage: <STAGE3>, ... } } } slotBasedPlan: { ... } },
각 단계는 결과 문서 또는 인덱스 키를 상위 노드에 전달합니다. 리프 노드는 컬렉션 또는 인덱스에 액세스합니다. 내부 노드는 하위 노드에서 생성된 문서 또는 인덱스 키를 사용합니다. 루트 노드는 MongoDB가 궁극적으로 결과 세트를 파생하는 단계를 나타냅니다.
단계는 작업에 대한 설명입니다. 예를 들어 다음과 같습니다.
COLLSCAN
컬렉션 스캔용IXSCAN
인덱스 키 스캔용FETCH
문서 검색용GROUP
문서 그룹화용SHARD_MERGE
샤드에서 결과를 병합하는 경우SHARDING_FILTER
샤드에서 고아 문서를 필터링하기 위해TS_MODIFY
Time Series 컬렉션 수정BATCHED_DELETE
내부적으로 일괄 처리되는 여러 문서를 삭제하는 경우(MongoDB 6.1부터).EXPRESS
정기적인 쿼리 계획을 우회하여 최적화된 인덱스 스캔 계획을 사용할 수 있는 제한된 쿼리 세트에 대한 단계 (버전 8.0 의 새로운 기능)EXPRESS
단계는 다음 중 하나일 수 있습니다.EXPRESS_CLUSTERED_IXSCAN
EXPRESS_DELETE
EXPRESS_IXSCAN
EXPRESS_UPDATE
MongoDB 5.1 및 이후 버전을 위한 Explain 출력
이 섹션에서는 MongoDB 5.1 이후에 대한 explain
출력을 보여 줍니다. 이전 버전의 MongoDB에 대한 출력 설명을 보려면 해당 버전의 문서를 참조하세요.
queryPlanner
explain.queryPlanner
정보는 쿼리 옵티마이저에서 선택한 플랜을 자세히 설명합니다.
이러한 예시는 MongoDB의 클래식 및 슬롯 기반 실행 엔진의 출력 구조를 결합할 수 있습니다. 대표성을 갖기 위한 것이 아닙니다. 실제 출력은 크게 다를 수 있습니다.
샤딩되지 않은 컬렉션의 경우 explain
은 다음 queryPlanner
정보를 반환합니다.
queryPlanner: { namespace: <string>, indexFilterSet: <boolean>, parsedQuery: { ... }, planCacheShapeHash: <hexadecimal string>, planCacheKey: <hexadecimal string>, maxIndexedOrSolutionsReached: <boolean>, maxIndexedAndSolutionsReached: <boolean>, maxScansToExplodeReached: <boolean>, winningPlan: { stage: <STAGE1>, inputStage: { stage: <string>, ... } }, rejectedPlans: [ <candidate plan1>, ] }
MongoDB 8.0 부터 기존 queryHash
필드 의 이름이 planCacheShapeHash
로 변경되었습니다. 이전 MongoDB 버전을 사용하는 경우 planCacheShapeHash
queryHash
가 표시됩니다.
샤딩된 컬렉션의 경우 explain
에는 shards
필드의 액세스된 각 샤드에 대한 핵심 쿼리 플래너 및 서버 정보가 포함됩니다.
{ queryPlanner: { mongosPlannerVersion: <int> winningPlan: { stage: <STAGE1>, 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>, inputStage: { stage: <string>, ... } }, rejectedPlans: [ <candidate plan1>, ] } ] } } }
MongoDB 8.0 부터 기존 queryHash
필드 의 이름이 planCacheShapeHash
로 변경되었습니다. 이전 MongoDB 버전을 사용하는 경우 planCacheShapeHash
queryHash
가 표시됩니다.
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 버전을 사용하는 경우planCacheShapeHash
queryHash
가 표시됩니다.계획 캐시 쿼리 형태의 해시를 나타내는 16진수 문자열로 계획 캐시 쿼리 형태에만 종속됩니다.
planCacheShapeHash
는 동일한 계획 캐시 쿼리 형태를 가진 느린 쿼리(쓰기 작업의 쿼리 필터 포함)를 식별하는 데 도움이 될 수 있습니다.참고
다른 해시 함수와 마찬가지로, 두 개의 다른 계획 캐시 쿼리 형태가 동일한 해시 값을 생성할 수 있습니다. 그러나 서로 다른 계획 캐시 쿼리 형태 간에 해시 충돌이 발생할 가능성은 거의 없습니다.
planCacheShapeHash
및planCacheKey
에 대한 자세한 내용은 planCacheShapeHash 및 planCacheKey를 참조하세요.
explain.queryPlanner.planCacheKey
쿼리와 연관된 계획 캐시 항목에 대한 키의 해시입니다.
explain.queryPlanner.planCacheShapeHash
와는 달리explain.queryPlanner.planCacheKey
는 계획 캐시 쿼리 형태 와 해당 형태에 대해 현재 사용 가능한 인덱스 모두의 함수입니다. 구체적으로 쿼리 형태를 지원할 수 있는 인덱스가 추가되거나 삭제되면planCacheKey
값은 변경될 수 있지만planCacheShapeHash
값은 변경되지 않습니다.planCacheShapeHash
및planCacheKey
에 대한 자세한 내용은 planCacheShapeHash 및 planCacheKey를 참조하세요.
explain.queryPlanner.optimizationTimeMillis
쿼리 플래너가 쿼리 최적화에 소요한 시간(밀리초)입니다. 이 결과에는 내부
$lookup
쿼리를 최적화하는 데 소요된 시간은 포함되지 않습니다.버전 8.0에 추가 되었습니다.
explain.queryPlanner.optimizedPipeline
전체 집계 파이프라인 작업이 최적화되고 대신 쿼리 계획 실행 단계 트리에 의해 이행되었음을 나타내는 부울입니다.
예를 들어, 다음 집계 작업은 집계 파이프라인을 사용하지 않고 쿼리 계획 실행 트리에서 수행할 수 있습니다.
db.example.aggregate([ { $match: { someFlag: true } } ] ) 이 필드는 값이
true
인 경우에만 표시되며 집계 파이프라인 작업에 대한 설명에만 적용됩니다.true
인 경우 파이프라인이 최적화되었기 때문에 집계 단계 정보가 출력에 표시되지 않습니다.
explain.queryPlanner.winningPlan
쿼리 최적화 프로그램에서 선택한 계획을 자세히 설명하는 문서입니다.
explain.queryPlanner.winningPlan.stage
단계의 이름을 나타내는 문자열입니다.
각 단계는 해당 단계에 맞는 정보로 구성됩니다. 예를 들어,
IXSCAN
단계에는 인덱스 스캔과 관련된 다른 데이터와 함께 인덱스 경계가 포함됩니다. 스테이지에 하위 스테이지가 하나 또는 여러 개 있는 경우 스테이지에는inputStage
또는inputStages
가 있습니다.이 필드는 작업에서 클래식 쿼리 실행 엔진을 사용한 경우 나타납니다.
explain.queryPlanner.winningPlan.inputStage
상위 단계에 문서 또는 인덱스 키를 제공하는 하위 단계를 설명하는 문서입니다. 이 필드는 상위 단계에 하위 단계가 하나만 있는 경우에 표시됩니다.
explain.queryPlanner.winningPlan.inputStages
하위 단계를 설명하는 문서 배열입니다. 하위 단계는 상위 단계에 문서 또는 인덱스 키를 제공합니다. 부모 스테이지에 여러 자식 노드가 있는 경우 이 필드가 표시됩니다. 예를 들어 $or 표현식에 대한 단계는 여러 소스의 입력을 사용할 수 있습니다.
이 필드는 작업에서 클래식 쿼리 실행 엔진을 사용한 경우 나타납니다.
explain.queryPlanner.winningPlan.isCached
winPlan이 계획 캐시 에 있는지 여부를 나타내는 부울입니다.
이 필드 는 성공적인 계획과 거부된 계획 사이에 최대 하나의 계획에 대해
true
입니다. 쿼리 에 캐시된 계획이 없는 경우 성공 계획 및 거부된 계획에 대한 필드 는false
입니다.
explain.queryPlanner.winningPlan.queryPlan
쿼리 최적화 프로그램에서 선택한 계획을 자세히 설명하는 문서입니다. MongoDB는 계획을 단계별 트리로 표시합니다.
이 문서는 쿼리가 슬롯 기반 실행 쿼리 엔진을 사용한 경우에 나타납니다.
버전 5.1에 추가되었습니다.
explain.queryPlanner.winningPlan.queryPlan.stage
단계의 이름을 나타내는 문자열입니다.
각 단계는 해당 단계에 맞는 정보로 구성됩니다. 예를 들어,
IXSCAN
단계에는 인덱스 스캔과 관련된 다른 데이터와 함께 인덱스 경계가 포함됩니다.
explain.queryPlanner.winningPlan.queryPlan.planNodeId
실행 계획의 각 단계를 식별하는 고유한 정수 필드입니다. 필드는
explain
결과의 모든 단계에 포함되어 있습니다.버전 5.1에 추가되었습니다.
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을 실행해야 합니다.
allPlansExecution 세부 정보 표시 모드입니다.
allPlansExecution
모드를 사용하여 계획 선택 중에 캡처한 부분 실행 데이터를 포함할 수 있습니다.
이러한 예시는 MongoDB의 클래식 및 슬롯 기반 실행 엔진의 출력 구조를 결합할 수 있습니다. 대표성을 갖기 위한 것이 아닙니다. 실제 출력은 크게 다를 수 있습니다.
샤딩되지 않은 컬렉션의 경우 explain
은 다음 executionStats
정보를 반환합니다.
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>, ... inputStage: { ... } } }, allPlansExecution: [ { nReturned: <int>, executionTimeMillisEstimate: <int>, totalKeysExamined: <int>, totalDocsExamined:<int>, 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> } }
샤딩된 컬렉션의 경우 explain
에는 액세스된 각 샤드에 대한 실행 통계가 포함됩니다.
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 ... 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.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.bucketFilter
Time Series 컬렉션 작업에서 버킷 카탈로그에서 쿼리된 버킷 수를 줄이는 데 사용되는 필터입니다.
explain.executionStats.executionStages.residualFilter
Time Series 컬렉션에 대한 작업에서 버킷 카탈로그를 쿼리 하는 데 사용되는 필터하다 입니다.
explain.executionStats.executionStages.nBucketsUnpacked
Time Series 컬렉션 작업에서 작업을 해결하기 위해 언팩된 버킷 수입니다.
explain.executionStats.executionStages.inputStage
각
inputStage
는inputStage.stage
의 값에 따라 다른 필드를 가질 수 있습니다. 다음 표에서는 가능한 필드와 해당 필드가 표시될 수 있는 단계에 대해 설명합니다.각
inputStage
는 다른inputStage
를 필드로 가질 수 있습니다. 출력 구조 설명을 참조하세요.필드설명적용 가능한 단계docsExamined
쿼리 실행 단계에서 스캔되는 문서 수를 지정합니다.
COLLSCAN
,FETCH
keysExamined
쿼리 실행 단계에서 인덱스
keysExamined
는 인덱스 스캔 프로세스에서 검사되는 내부 및 범위를 벗어난 키의 총 수입니다. 인덱스 스캔이 단일 연속 키 범위로 구성된 경우 인바운드 키만 검사하면 됩니다. 인덱스 경계가 여러 키 범위로 구성된 경우 인덱스 스캔 실행 프로세스에서 범위를 벗어난 키를 검사하여 한 범위의 끝에서 다음 범위의 시작으로 건너뛸 수 있습니다.IXSCAN
numReads
쿼리 실행 단계에서 검사된 문서 수 또는 검사된 인덱스 키 수입니다.
버전 5.1에 추가되었습니다.
COLLSCAN
,IXSCAN
seeks
인덱스 스캔을 완료하기 위해 인덱스 커서를 새 위치로 이동해야 했던 횟수입니다.
IXSCAN
spilledBytesApprox
해당 단계에서 디스크로 유출된 메모리 내 바이트의 대략적인 수입니다.
버전 5.3에 추가.
GROUP
spilledRecords
해당 단계에서 디스크로 유출된 생성된 레코드 수입니다.
버전 5.3에 추가.
GROUP
usedDisk
해당 단계가 디스크를 썼는지 여부입니다.
버전 5.3에 추가.
GROUP
explain.executionStats.allPlansExecution
채택된 계획과 거부된 계획 모두에 대해 계획 선택 단계에서 캡처한 부분 실행 정보를 포함합니다. 이 필드는
explain
가allPlansExecution
세부 정보 표시 모드에서 실행되는 경우에만 표시됩니다.
explain.executionStats.operationMetrics
리소스 소비 통계가 0이 아닌 한 포함됩니다. 이 필드는
explain
이executionStats
세부 정보 표시 모드 이상에서 실행되고profileOperationResourceConsumptionMetrics
가 활성화된 경우에만 표시됩니다.
serverInfo
샤딩되지 않은 컬렉션의 경우 explain
은 MongoDB 인스턴스에 대해 다음 serverInfo
정보를 반환합니다.
serverInfo: { host: <string>, port: <int>, version: <string>, gitVersion: <string> }
샤딩된 컬렉션의 경우 explain
은(는) 액세스된 각 샤드에 대해 serverInfo
을(를) 반환하고 mongos
에 대해 최상위 serverInfo
객체를 반환합니다.
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> } ...
파이프라인 단계가 인 쿼리에 대한 $lookup
실행 계획 통계
버전 5.0에 추가.
설명 결과에는 $lookup
파이프라인 단계를 사용하는 쿼리에 대한 실행 통계가 포함될 수 있습니다. 이러한 실행 통계를 포함하려면 다음 실행 상세 모드 중 하나에서 설명 작업을 실행해야 합니다.
다음 필드는 $lookup
쿼리에 대한 Explain 결과에 포함됩니다.
'$lookup': { from: <string>, as: <string>, localField: <string>, foreignField: <string> }, totalDocsExamined: <long>, totalKeysExamined: <long>, collectionScans: <long>, indexesUsed: [ <string_1>, <string_2>, ..., <string_n> ], executionTimeMillisEstimate: <long>
$lookup
섹션의 필드에 대한 설명을 보려면 $lookup
페이지를 참조하십시오.
다른 필드는 다음과 같습니다.
컬렉션 스캔
쿼리 플래너가 컬렉션 검색을 선택하면 설명 결과에 COLLSCAN
단계가 포함됩니다.
쿼리 플래너가 인덱스를 선택하면 explain 결과에 IXSCAN
단계가 포함됩니다. 이 단계에는 인덱스 키 패턴, 순회 방향, 인덱스 범위 등의 정보가 포함됩니다.
MongoDB 5 3부터 쿼리 플래너가 클러스터형 컬렉션에 대한 클러스터형 인덱스를 선택하고 쿼리에 검색할 인덱스 부분을 정의하는 경계가 포함되어 있는 경우 설명 결과에 CLUSTERED_IXSCAN
단계가 포함됩니다. 이 단계에는 클러스터된 인덱스 키 및 인덱스 바운드에 대한 정보가 포함되어 있습니다.
쿼리 플래너가 클러스터형 컬렉션에 대한 클러스터형 인덱스를 선택하고 쿼리에 경계가 포함되어 있지 않은 경우 쿼리는 무제한 컬렉션 스캔을 수행하고 설명 결과에 COLLSCAN
단계가 포함됩니다.
참고
쿼리에는 전체 컬렉션 스캔이 필요하므로 notablescan
매개 변수는 클러스터형 인덱스를 사용하는 무제한 쿼리를 허용하지 않습니다.
자세한 컬렉션 스캔 실행 통계 내용은 설명 계획 결과 해석에서 확인하세요.
지원되는 쿼리
인덱스가 쿼리를 포함하는 경우 MongoDB는 쿼리 조건을 일치시키고 또한 인덱스 키만을 사용하여 결과를 반환할 수 있습니다. MongoDB는 특정 쿼리 부문을 수행하기 위해 컬렉션의 문서를 검사할 필요가 없습니다.
인덱스가 쿼리를 포함하는 경우 설명 결과에는 FETCH
단계의 하위 단계가 아닌 IXSCAN
단계가 있으며 executionStats
에서 explain.executionStats.totalDocsExamined
는 0
입니다.
$or
표현식
MongoDB가 $or
표현식에 인덱스를 사용하는 경우, 결과에는 인덱스를 자세히 설명하는 explain.queryPlanner.winningPlan.inputStages
배열이 있는 OR
단계가 포함됩니다. 예:
{ stage: 'OR', inputStages: [ { stage: 'IXSCAN', ... }, { stage : 'IXSCAN', ... }, ... ] }
이전 버전의 MongoDB에서는 cursor.explain()
색인을 자세히 설명하는 clauses
배열을 반환했습니다.
$sort
및 $group
단계
explain
이 executionStats 또는 allPlansExecution 세부 정보 표시 모드에서 실행되면 $sort
및 $group
단계에 추가 출력이 있습니다.
단계 | 필드 | 유형 | 설명 |
---|---|---|---|
| long |
| |
| 부울 |
| |
| long |
| |
| 부울 |
| |
| long |
| |
| long | 압축 전 |
정렬 단계
MongoDB가 하나 이상의 인덱스를 사용하여 정렬 순서를 가져올 수 없는 경우 결과에는 차단 정렬 작업을 나타내는 SORT
단계가 포함됩니다. 차단 정렬은 컬렉션이나 데이터베이스에서 동시 작업을 차단하지 않습니다. 이름은 SORT
가 출력 문서를 반환하기 전에 모든 입력 문서를 읽어 해당 특정 쿼리에 대한 데이터 흐름을 차단해야 한다는 요구 사항을 나타냅니다.
MongoDB에서 차단 정렬 작업에 100 메가바이트 이상의 시스템 메모리를 사용해야 하는 경우 쿼리에서 cursor.allowDiskUse()
를 지정하지 않는 한 MongoDB에서 오류를 반환합니다. cursor.allowDiskUse()
를 사용하면 MongoDB가 디스크의 임시 파일을 사용하여 차단 정렬 작업을 처리하는 동안 100 메가바이트 시스템 메모리 제한을 초과하는 데이터를 저장할 수 있습니다. 설명 계획에 명시적인 SORT
단계가 포함되어 있지 않으면 MongoDB는 인덱스를 사용하여 정렬 순서를 얻을 수 있습니다.
쿼리 형태 해시
MongoDB 8.0부터 explain
은 다음 필드를 출력합니다.