대부분 완료된 작업 테이블에서 대기 중인 작업만 자주 찾습니다. 부분 인덱스를 쓰려면 어떤 조건을 확인하나요?

부분 또는 필터 인덱스는 전체 행이 아니라 조건에 맞는 일부 행만 저장해 크기와 유지 비용을 줄이는 방법입니다. 쿼리 조건이 인덱스 조건에 포함되는 행만 요구한다는 것을 옵티마이저가 판단할 수 있어야 합니다.

동작 원리와 전제

status='pending' 행만 인덱싱하면 오래된 완료 작업이 커져도 대기 조회의 인덱스는 작을 수 있습니다. 그러나 파라미터 값이 컴파일 때 확정되지 않거나 조건 표현이 다르면 사용하지 않을 수 있습니다. 제품별 지원 문법과 predicate 추론을 실제 계획으로 확인합니다.

선택과 실패 처리

행이 pending에서 done으로 바뀌면 해당 인덱스에서 제거하는 쓰기 비용이 듭니다. 활성 사용자만 이메일 유일성을 적용하는 용도로도 쓸 수 있지만 삭제·복구 때 충돌 정책이 필요합니다. 일부 엔진은 같은 기능을 다른 표현으로 구현해야 하므로 이식성을 고려합니다.

구체적인 사례와 검증

활성 행만 유일한 이메일을 유지하면 탈퇴 사용자의 이메일을 새 사용자가 재사용할 수 있습니다. 이때 탈퇴 계정을 복구하려 하면 활성 고유 제약과 충돌할 수 있어 복구 정책을 따로 정해야 합니다. 부분 인덱스는 삭제된 데이터의 의미를 자동 결정하지 않습니다. pending 작업 인덱스도 전체 행 중 pending 비율이 크게 늘면 더 이상 작은 인덱스가 아닐 수 있습니다. 상태 분포와 갱신량을 관찰하고 쿼리가 조건을 정확히 포함하는지 확인합니다. 인덱스 생성 당시의 작은 샘플에서 얻은 이점을 운영의 모든 시점에 일반화하지 않겠습니다.

부분 집합 크기 변화·파라미터 계획·상태 전환 부하와 복구 경쟁을 시험합니다. 조건을 바꾸려면 새 인덱스 생성·검증·전환의 비용도 봅니다. 인덱스가 작다는 이점과 쿼리에서 그 범위를 증명할 수 있는 조건을 함께 설명하겠습니다.