"queryPlanner"는 데이터베이스 시스템(또는 데이터 처리 엔진)에서 주어진 쿼리를 가장 효율적으로 실행하기 위한 실행 계획을 생성·선택하는 구성요소 또는 그에 대한 정보입니다. 핵심 내용을 간단히 정리하면 다음과 같습니다. 정의와 역할 - 쿼리를 어떻게 실행할지 결정: 가능한 여러 실행 방식(인덱스 사용, 전체 스캔, 조인 순서 등)을 생성하고 비용을 추정해 최적의 계획을 선택. - 입력: SQL/쿼리문, 통계(테이블/인덱스 통계), 현재 인덱스와 제약조건 등. - 출력: 선택된 실행 계획(winning plan)과 경우에 따라 고려된 다른 계획들(rejected plans), 비용 추정치 등. 주요 구성 요소·동작 - 파싱/해석: 쿼리 구조를 파악하고 논리적 표현으로 변환. - 변환·재작성: 동등한 다른 형태로 변형(예: 뷰 전개, 상수 폴딩). - 비용 산정(cost estimation): 각 연산(스캔, 인덱스 접근, 조인 등)의 비용을 모델링하고 총비용을 계산. - 계획 탐색(plan search): 가능한 접근 경로·조인 순서 등을 조합해 후보 계획들을 생성. - 선택: 비용이 가장 낮은 계획을 선택(또는 휴리스틱 기반 선택). - 캐시/재사용: 자주 쓰이는 계획은 캐시에 저장해 재활용하기도 함(예: parameter sniffing 관련 이슈 발생). 출력에 포함되는 정보(예시) - 선택된 계획(예: winningPlan 또는 chosen plan)과 그 연산 트리(스캔, 인덱스 스캔, 조인 타입 등). - 비용 추정치(예상 비용, 예상 반환 행 수). - 고려되었으나 기각된 다른 계획들(일부 엔진은 보여줌). - 통계·제약정보(사용된 인덱스, 필터 조건 등). 시스템별 특이점(간단) - MongoDB: explain() 결과에서 queryPlanner 필드에 winningPlan, rejectedPlans, parsedQuery 등이 포함되어 실제 계획 구조를 확인 가능. - PostgreSQL/MySQL/Oracle 등 RDBMS: 쿼리 플래너/옵티마이저가 조인 순서, 접근 경로, 실행 방법(선형/해시 조인 등)을 결정하며 EXPLAIN / EXPLAIN ANALYZE로 확인 가능. 실무에서의 중요성 및 주의점 - 성능 영향이 큼: 잘못된(또는 오래된 통계로 인한) 계획은 쿼리 성능을 크게 저하시킬 수 있음. - 통계 갱신 필요: 정확한 통계가 있어야 비용추정과 선택이 정확해짐. - 계획 안정성 문제: 파라미터 민감성(parameter sniffing), 플랜 캐시로 인한 부적절한 재사용 문제 등이 발생할 수 있음. - 튜닝 수단: 인덱스 생성, 힌트 사용, 통계 수집, 쿼리 재작성, 옵티마이저 설정 변경 등으로 영향을 줌. 요약 - queryPlanner는 쿼리를 효율적으로 실행하기 위한 계획을 생성·비교·선택하는 엔진 또는 그 결과를 의미하며, 성능 최적화의 핵심 포인트입니다.
