간단히: MongoDB의 explain() 결과에 나오는 "winningPlan"은 쿼리 플래너가 후보(plan)들 중에서 실제로 선택한 실행 계획(플랜)을 의미합니다. 쿼리를 처리할 때 여러 가능한 플랜을 평가한 뒤 최종적으로 선택되어 실행(또는 캐시)된 그 플랜의 구조와 세부 정보를 보여줍니다. 주요 내용 및 해석 방법 - 위치: db.collection.find(...).explain(...) 결과의 최상위(queryPlanner 또는 executionStats 블록)에서 확인합니다. - 역할: 어떤 인덱스를 사용했는지, 어떤 스테이지(stages: COLLSCAN, IXSCAN, FETCH, SORT 등)를 거치는지, 내부적으로 어떤 연산 순서로 문서를 처리하는지를 설명합니다. - 구성 요소: - stage (또는 stages / inputStage 등): 실행 흐름의 단계(예: COLLSCAN = 컬렉션 스캔, IXSCAN = 인덱스 스캔, FETCH = 문서 조회, SORT = 메모리 정렬 등). - indexName: 사용된 인덱스 이름(있을 경우). - keysExamined / docsExamined: 인덱스 키와 문서가 각각 얼마나 검사되었는지(성능 문제 진단에 중요). - nReturned: 클라이언트에 반환된 문서 수. - executionTimeMillis (executionStats 모드에서): 실제 실행에 걸린 시간. - inputStages / childStage: 복합 플랜의 하위 단계 구조를 표현. - rejectedPlans: explain("allPlansExecution")에서는 다른 후보 플랜들의 실행 통계도 볼 수 있고, winningPlan은 그중 선택된 하나임을 알 수 있습니다. 때때로 후보들도 일부 실행되어 비교됩니다. - 캐시·재계획: winningPlan은 쿼리 플랜 캐시에 저장될 수 있습니다. 실행 중 성능이 나쁘면 MongoDB가 재계획(replanning)하거나 다른 플랜으로 전환할 수 있습니다. 실무에서의 활용 포인트 - COLLSCAN이 보이면 인덱스 부재로 전체 스캔을 하고 있는지 확인하세요. - keysExamined >> nReturned 이거나 docsExamined가 지나치게 크면 인덱스가 적절히 사용되지 않거나 필터/정렬가 비효율적임을 의미합니다. - SORT가 메모리 정렬(파일 정렬)으로 표시되면 인덱스로 정렬을 지원하도록 쿼리/인덱스를 조정하세요. - 복잡한 쿼리는 explain("allPlansExecution")로 후보 플랜의 비교 통계를 보고 최종 선택 이유를 분석하세요. - 계획 캐시를 비우거나 인덱스를 추가·변경한 뒤 explain으로 변경된 winningPlan을 확인하세요. 요약하면, winningPlan은 쿼리 실행에 실제로 채택된 계획의 청사진으로, 쿼리 성능 진단과 인덱스·쿼리 튜닝에 가장 먼저 확인해야 할 정보입니다.
