PREWHERE — 넓은 테이블에서 두 단계로 나눠 컬럼을 읽는 최적화
ClickHouse PREWHERE 및 Parallel Replicas 공식 문서 종합 (웹 리서치, 2026) — ClickHouse 공식 문서(sql-reference/statements/select/prewhere, deployment-guides/parallel-replicas) ClickHouse 공식 문서 PREWHERE clause
이 모듈을 다 읽으면
- PREWHERE가 WHERE와 달리 컬럼 읽기를 두 단계로 나누는 방식을 설명할 수 있다
- 이 최적화가 자동으로 적용되는 조건과 명시적으로 꺼야 하는 상황을 설명할 수 있다
clickhouse-learn-01에서 다룬 컬럼 지향 저장(쿼리가 필요한 컬럼만 골라 읽는 특성)을 한 단계 더 활용해, 필터 조건에 필요한 컬럼만 먼저 읽어 걸러낸 뒤 나머지 컬럼은 살아남은 행에 대해서만 읽는 PREWHERE 최적화를 정리한다.
두 단계 읽기 — 조건 평가용 컬럼 먼저, 나머지는 살아남은 블록만
일반 WHERE는 쿼리가 요청한 모든 컬럼을 먼저 읽은 뒤 최종 결과를 필터링하는 것과 개념적으로 다르게, PREWHERE는 (1) 먼저 조건 평가에 필요한 컬럼만 읽어 조건을 계산하고, (2) 그 결과 최소 하나 이상의 행이 매칭되는 블록에 대해서만 쿼리가 요청한 나머지 컬럼들을 읽는다 — 즉 컬럼을 읽는 자체를 2단계로 나눠, 애초에 조건에 안 맞는 블록의 다른 컬럼들은 디스크에서 읽지도 않는다. 넓은 테이블(컬럼이 많은 테이블)에서 소수의 컬럼만으로 대부분의 행을 걸러낼 수 있을 때 I/O를 극적으로 줄여준다.
핵심 포인트
- PREWHERE는 조건 평가용 컬럼을 먼저 읽어 필터링하고, 매칭 행이 있는 블록에 대해서만 나머지 컬럼을 읽는 2단계 읽기
- 넓은 테이블에서 소수 컬럼만으로 대부분의 행을 걸러낼 수 있을 때 I/O를 극적으로 줄임
자동 최적화 — optimize_move_to_prewhere
ClickHouse는 기본적으로 optimize_move_to_prewhere 설정에 따라 WHERE 조건 중 적합한 것들을 자동으로 PREWHERE로 옮겨 적용한다 — 사용자가 직접 PREWHERE를 명시적으로 쓰지 않아도 옵티마이저가 알아서 이 최적화를 적용해준다는 뜻이다. 다만 FINAL 수정자를 쓰는 쿼리에서는 이 자동 전환이 optimize_move_to_prewhere와 optimize_move_to_prewhere_if_final 두 설정이 모두 켜져 있어야 적용된다.
핵심 포인트
- optimize_move_to_prewhere 설정으로 WHERE 조건 중 적합한 것을 옵티마이저가 자동으로 PREWHERE로 전환
- FINAL 수정자를 쓰는 쿼리는 optimize_move_to_prewhere + optimize_move_to_prewhere_if_final 둘 다 켜져야 자동 전환됨
제약 — MergeTree 계열 전용, JOIN에서는 조심
PREWHERE는 *MergeTree 계열 테이블에서만 지원된다. 또한 JOIN 쿼리에서는 PREWHERE 조건이 최대 한 테이블의 컬럼만 참조할 수 있고 WHERE와 다르게 동작할 수 있어, 특히 OUTER JOIN에서는 예상과 다른 결과를 낳을 위험이 있다 — 그래서 JOIN이 섞인 쿼리에서 PREWHERE를 직접 명시할 때는 각별한 주의가 필요하다. 이 최적화는 필터가 소수 컬럼으로 표현되고 많은 행을 걸러낼 수 있을 때 가장 효과적이다.
핵심 포인트
- PREWHERE는 *MergeTree 계열 테이블 전용
- JOIN 쿼리에서는 최대 한 테이블 컬럼만 참조 가능하고 OUTER JOIN에서 예상과 다른 결과 위험 — 필터가 소수 컬럼+많은 행 제거일 때 가장 효과적