`. 테이블에서 PK, 파티션, 기존 인덱스 프루닝을 거친 뒤 남은 비율, 즉 hypothetical index의 입력이 되는 범위를 보여줍니다.
* `est_bytes` — 읽기 바이트 수의 추정치입니다. 테이블의 평균 행 크기를 바탕으로 계산하므로 근사치이며, 스토리지와 Compression에 따라 달라집니다. 기준선 행은 쿼리가 행을 읽을 때만 표시되며, 각 후보 행은 기준선 바이트 추정치를 알 수 있을 때만 표시됩니다.
이 설정은 `WHATIF`와 `SELECT` 사이에 인라인으로 작성하며, `SETTINGS` keyword는 없습니다(다른 `EXPLAIN` 변형이 옵션을 받는 방식과 동일합니다).
테이블에 hypothetical index가 정의되어 있지 않으면 `EXPLAIN WHATIF`는 `status: not_applicable`와 함께 생성하라는 힌트를 보고합니다.
**결합 행(여러 후보)**
두 개 이상의 후보를 empirical 방식으로 평가하면 `EXPLAIN WHATIF`는 후보별 행 뒤에 `(combined: idx_a, idx_b, ...)`라는 이름의 추가 블록 1개를 덧붙입니다. 이 블록은 해당 인덱스들을 *모두* 동시에 적용했을 때의 전체 효과를 보고합니다. 실제 읽기에서는 그래뉼이 *모든* 스킵 인덱스를 통과한 경우에만 유지되므로, 결합 추정치는 후보별 생존 그래뉼의 교집합이 됩니다. 따라서 `skip_ratio`는 가장 성능이 좋은 단일 후보보다 최소한 같거나 더 높습니다. 상호 보완적인 인덱스는 함께 더 많이 프루닝하고, 중복되는 인덱스는 결과를 바꾸지 않습니다.
`source: empirical`인 후보만 반영됩니다. 결합된 행은 각 후보의 그래뉼별 생존 Set의 교집합으로 만들어지기 때문입니다. `statistical` 또는 `applicability_only`로 추정된 후보에는 그래뉼별 데이터가 없으므로 제외됩니다. 따라서 결합된 블록은 최소 2개의 후보가 경험적 추정치를 생성한 경우에만 나타나며, 그렇지 않으면(예: `empirical = 0`인 경우) 생략됩니다. 추정 필드는 후보별 경험적 블록과 동일하지만, `elapsed_us`는 `0`입니다 — 결합된 추정치는 새로운 스캔이 아니라 후보별 스캔에서 파생되기 때문입니다. 합성된 `(combined: ...)` 이름은 보고서 레이블일 뿐이며 `force_data_skipping_indices`와 함께 사용할 수 없습니다.
**경험적 예시**
```sql theme={null}
CREATE TABLE t (a UInt64, b UInt64) ENGINE = MergeTree ORDER BY a
SETTINGS index_granularity = 100;
INSERT INTO t SELECT number, number FROM numbers(10000);
CREATE HYPOTHETICAL INDEX idx_b ON t (b) TYPE minmax GRANULARITY 1;
EXPLAIN WHATIF SELECT * FROM t WHERE b = 42;
```
```text theme={null}
Baseline (after PK + partition + existing indexes):
table: default.t
parts: 1
marks: 100
est_bytes: 85.52 KiB
With idx_b (minmax, hypothetical):
status: applicable
marks: 1
est_bytes: 875.00 B
skip_ratio: 99.0%
Estimation:
source: empirical
empirical_status: ok
sampled_parts: 1 / 1
sampled_marks: 100 / 100
```
가상의 `minmax`는 100개의 마크를 1개로 걸러낼 수 있습니다 — `skip_ratio: 99.0%`. (`est_bytes`는 평균 행 크기를 기준으로 한 추정치이므로 정확한 값은 달라질 수 있습니다.)
**통계 예시**
컬럼 [통계](/docs/ko/reference/engines/table-engines/mergetree-family/mergetree#column-statistics)는 기본적으로 비활성화되어 있습니다. `statistical` 경로를 테스트하려면 먼저 관련 컬럼에 이를 정의하고 구체화 mutation이 완료될 때까지 기다리십시오:
```sql theme={null}
ALTER TABLE t ADD STATISTICS b TYPE TDigest;
ALTER TABLE t MATERIALIZE STATISTICS b SETTINGS mutations_sync = 1;
```
그런 다음 추정기가 컬럼 통계를 대신 사용하도록 경험적 경로를 비활성화합니다:
```sql theme={null}
EXPLAIN WHATIF empirical = 0 SELECT * FROM t WHERE b < 10;
```
```text theme={null}
With idx_b (minmax, hypothetical):
status: applicable
marks: 1
est_bytes: 1.66 KiB
skip_ratio: 99.9%
Estimation:
source: statistical
empirical_status: disabled
```
이 값은 `b < 10`의 컬럼 통계 선택도(selectivity)에서 나오며(10000개 행 중 약 10개 행), `skip_ratio`의 상한값으로 보고됩니다. `sampled_parts` / `sampled_marks`는 없으며, 데이터를 읽지 않았습니다.
두 경로 모두 사용할 수 없으면(예: `empirical = 0`이고 컬럼 통계가 정의되지 않은 경우), 추정기는 `source: applicability_only`와 보수적인 `skip_ratio: 0.0%`를 보고합니다.
### EXPLAIN TABLE OVERRIDE
테이블 함수를 통해 접근한 테이블 스키마(schema)에 테이블 재정의를 적용한 결과를 보여줍니다.
또한 일부 유효성 검사도 수행하며, 이 재정의로 인해 어떤 형태로든 실패가 발생할 경우 예외를 발생시킵니다.
**예시**
원격 MySQL 테이블이 다음과 같다고 가정합니다:
```sql title="Query" theme={null}
CREATE TABLE db.tbl (
id INT PRIMARY KEY,
created DATETIME DEFAULT now()
)
```
```sql title="Query" theme={null}
EXPLAIN TABLE OVERRIDE mysql('127.0.0.1:3306', 'db', 'tbl', 'root', 'clickhouse')
PARTITION BY toYYYYMM(assumeNotNull(created))
```
```text title="Response" theme={null}
┌─explain─────────────────────────────────────────────────┐
│ PARTITION BY uses columns: `created` Nullable(DateTime) │
└─────────────────────────────────────────────────────────┘
```
검증이 완전하지 않으므로, 쿼리가 성공하더라도 재정의로 인해 문제가 발생하지 않는다고 보장할 수는 없습니다.