파티션 프루닝 검증

Oracle

EXPLAIN PLAN FOR
SELECT * FROM sale WHERE sale_date = DATE '2026-01-15';
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
-- Look for 'PARTITION RANGE ITERATOR/SINGLE' and the Pstart/Pstop columns in the plan.

Pstart/Pstop은 관련 파티션만 읽는다는 것을 보여 준다(KEY보다 숫자가 이상적). 파티션 키에 함수/암묵적 변환을 적용하면 프루닝이 되지 않는다.

PostgreSQL

SET enable_partition_pruning = on;
EXPLAIN (ANALYZE)
SELECT * FROM sale WHERE sale_date = DATE '2026-01-15';
-- Verify in the plan that only the relevant partition (child table) is scanned.

enable_partition_pruning이 켜져 있으면 일치하는 파티션만 실행 계획에 나타나며, 나머지는 'never executed'로 표시된다. 상수 값은 계획 시점에, 파라미터는 실행 시점에 프루닝된다.

MySQL

-- Show which partitions are scanned:
EXPLAIN SELECT * FROM sale WHERE sale_date = '2026-01-15';
-- 5.7 and earlier: EXPLAIN PARTITIONS SELECT ... (removed in 8.0)

MySQL 5.7+에서 일반 EXPLAIN 출력의 'partitions' 컬럼은 스캔할 파티션을 나열한다(EXPLAIN PARTITIONS 구문은 8.0에서 제거됨). 관련 파티션만 나타나야 하며, 모든 파티션이 나열되면 프루닝이 되지 않는 것이다.

SQL Server

-- Find which partition a value falls into:
SELECT $PARTITION.pf_sale_date('2026-01-15') AS partition_no;
-- Examine 'Actual Partition Count' and 'Actual Partitions Accessed' in the actual plan.

$PARTITION 함수는 값의 파티션 번호를 반환한다. 실제 실행 계획에서 접근한 파티션 수가 1에 가까우면 프루닝이 적용된 것이고, 모든 파티션을 스캔하면 조건절이 맞지 않는 것이다.

MongoDB

// Targeted query using the shard key in a sharded cluster:
db.sale.find({ shop_id: 42 }).explain("executionStats")
// In explain, only the relevant shard should appear under 'shards'.

쿼리에 샤드 키가 포함되면 mongos는 해당 샤드로만 라우팅한다(targeted). 그렇지 않으면 모든 샤드로 전파된다(scatter-gather). explain 출력에서 접근한 샤드를 확인한다.

Redis

# Not applicable: there is no table/partition concept.

데이터는 Cluster 해시 슬롯으로 분산되며, 쿼리 프루닝 대신 키로 직접 접근한다.

Elasticsearch

# Route to the relevant shard with routing:
GET <index>/_search?routing=customer42
{ "query": { "term": { "customer_id": 42 } } }
# Query only the relevant indices with a time-based index pattern:
GET sale-2026-01/_search

custom routing은 쿼리를 단일 샤드로 좁힌다(프루닝과 유사). 시계열 데이터는 날짜 패턴 인덱스 이름(sale-2026-01)을 사용하면 관련 인덱스만 검색된다. 와일드카드 대신 좁은 패턴을 사용한다.