날짜별로 테이블을 파티셔닝했는데 최근 하루 조회가 여전히 느립니다. partition pruning과 인덱스는 어떤 관계인가요?

파티션 제거는 조건에 필요 없는 파티션을 읽지 않는 최적화이고, 남은 파티션 안에서 행을 찾는 방법은 별도입니다. 날짜로 나눴다고 모든 질의가 빨라지거나 내부 인덱스가 불필요해지는 것은 아닙니다.

동작 원리와 전제

조회 조건이 파티션 키의 범위로 표현되면 관련 날짜만 남길 수 있습니다. 함수·암묵 변환·파라미터 계획 때문에 제거 시점이나 가능 여부가 달라질 수 있어 실제 실행에서 읽은 파티션 수를 확인합니다. 고객 ID만 조회하면 많은 파티션을 모두 찾아야 할 수 있습니다.

선택과 실패 처리

시간별 보관 삭제는 파티션 단위 detach·drop으로 단순해질 수 있지만 잠금·백업·참조 제약을 확인해야 합니다. 너무 많은 작은 파티션은 계획·메타데이터·파일 관리 비용을 늘립니다. 글로벌 유일성·외래키 지원도 엔진별로 다릅니다.

구체적인 사례와 검증

최근 하루 요청이 전체 5년 중 하루 파티션만 읽더라도 그 하루에 수억 행이 있으면 여전히 내부 인덱스가 필요합니다. 반대로 고객 ID 단독 조회는 모든 날짜 파티션에 같은 탐색을 반복할 수 있어 파티션 키 선택이 중요합니다. 보관 정책을 위해 날짜 분할을 택했다면 다른 조회의 비용을 인정하고 별도 읽기 모델을 둘지 봅니다. 지연 데이터가 이미 닫은 파티션으로 들어올 때 처리·오류·재개 정책도 정합니다. 파티션을 삭제하는 작업은 파일 관리가 아니라 데이터 보존 결정을 포함하므로 복구·백업·규정 범위를 확인한 뒤 실행해야 합니다.

날짜 경계·지연 입력·기본 파티션·과거 데이터 보정과 새 파티션 생성 실패를 시험합니다. 최근 범위 조회와 키 단독 조회의 계획·읽기·쓰기 비용을 함께 봅니다. 파티셔닝은 관리 단위와 접근 경로의 선택이며 샤딩처럼 여러 서버로 자동 분산하는 기능과는 구분합니다.