`. Показывает, какая доля таблицы осталась после pruning по PK, партициям и существующим индексам, то есть какие данные поступают на вход гипотетическому индексу.
* `est_bytes` — оценка количества прочитанных байтов, полученная на основе среднего размера строки в таблице, поэтому она приблизительна и зависит от хранилища и сжатия. Строка baseline появляется только тогда, когда запрос читает строки; строка для каждого кандидата — только когда известна базовая оценка объёма в байтах.
Настройка записывается inline между `WHATIF` и `SELECT` — ключевое слово `SETTINGS` отсутствует (это соответствует тому, как другие варианты `EXPLAIN` принимают свои параметры).
Если для таблицы не определены гипотетические индексы, `EXPLAIN WHATIF` возвращает `status: not_applicable` с подсказкой создать индекс.
**Комбинированная строка (несколько кандидатов)**
Когда два или более кандидата оцениваются эмпирически, `EXPLAIN WHATIF` добавляет ещё один блок с именем `(combined: idx_a, idx_b, ...)` после строк отдельных кандидатов. Он показывает совокупную пользу от наличия *всех* этих индексов одновременно: при реальном чтении гранула сохраняется только в том случае, если проходит через *каждый* индекс пропуска данных, поэтому комбинированная оценка представляет собой пересечение гранул, оставшихся после кандидатов. Следовательно, его `skip_ratio` как минимум не ниже, чем у лучшего отдельного кандидата: взаимодополняющие индексы вместе отсекают больше, а избыточные не меняют результат.
Учитываются только кандидаты с `source: empirical`, поскольку объединённая строка формируется путём пересечения их наборов выживания по гранулам. Кандидаты с оценкой `statistical` или `applicability_only` не имеют данных по гранулам и исключаются; соответственно, объединённый блок появляется только тогда, когда как минимум два кандидата дали эмпирическую оценку, и в остальных случаях опускается (например, при `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/ru/reference/engines/table-engines/mergetree-family/mergetree#column-statistics) по умолчанию отключена. Чтобы задействовать вариант `statistical`, сначала задайте её для нужных столбцов и дождитесь завершения мутации `materialize`:
```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` (примерно 10 строк из 10000) и приводится как верхняя граница для `skip_ratio`. Значения `sampled_parts` / `sampled_marks` отсутствуют — данные не считывались.
Если ни один из вариантов недоступен (например, `empirical = 0` и статистика столбцов не определена), оценщик возвращает `source: applicability_only` и консервативное значение `skip_ratio: 0.0%`.
### EXPLAIN TABLE OVERRIDE
Показывает результат переопределения таблицы в схеме таблицы, к которой обращаются через табличную функцию.
Также выполняет проверку и генерирует исключение, если такое переопределение привело бы к какой-либо ошибке.
**Пример**
Предположим, у вас есть удалённая таблица 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) │
└─────────────────────────────────────────────────────────┘
```
Проверка не является исчерпывающей, поэтому успешный запрос не гарантирует, что переопределение не приведёт к проблемам.