MyBatis 조회의 정합성과 실행계획을 함께 검토하기

문제

업무 조회는 선택 조건이 늘어날수록 하나의 거대한 조건식이 되기 쉽습니다. 이때 결과 중복·누락을 막으면서도 인덱스를 사용할 수 있게 해야 하며, 단순히 실행 시간이 짧아졌다는 이유만으로 정합성을 희생할 수 없습니다.

담당한 부분

비공개 Java/Spring·MyBatis 업무 코드에서 본인이 담당한 조회 조건 개선 범위를 확인했습니다. 복합 조건에서 결과의 중복과 누락을 점검하고, 입력값 정규화와 인덱스 사용 가능성을 함께 검토한 사례입니다.

설계 판단

• 의미가 다른 조건 경로는 하나의 복잡한 OR에 숨기지 않고 독립 집합으로 분리한 뒤 합칩니다.
• 검색 열에 함수를 적용해 인덱스 후보를 없애는 형태를 피하고, 입력값을 먼저 정규화합니다.
• 화면 응답과 오래 걸리는 후속 처리를 같은 요청에 묶지 않습니다.
• 변경 전후 결과 집합을 비교하는 회귀 검증을 성능 측정보다 먼저 둡니다.

대안과 trade-off

쿼리를 잘게 나누면 중복 제거와 정렬 비용이 생길 수 있고, materialized view 같은 사전 계산은 갱신 지연을 받아들여야 합니다. 따라서 조회 빈도, 데이터 변경 주기와 최신성 요구를 함께 비교해야 합니다.

현재 공개 범위

실제 테이블명, SQL, 데이터, 내부 경로와 성능 수치는 포함하지 않았습니다. 현재 글은 확인된 담당 범위와 설계 판단만 일반화한 것으로, 공개 재현 코드나 실행계획 비교 결과·최근 테스트는 아직 포함하지 않습니다.