`. Muestra qué fracción de la tabla quedó tras la poda por PK, partición e índices existentes; es decir, la entrada del índice hipotético.
* `est_bytes` — una estimación de los bytes leídos, derivada del tamaño medio de fila de la tabla, por lo que es aproximada y varía según el almacenamiento y la compresión. La línea de base aparece solo cuando la consulta lee filas; la línea por candidato, solo cuando se conoce la estimación de bytes de la línea de base.
La configuración se escribe en línea entre `WHATIF` y `SELECT`; no hay palabra clave `SETTINGS` (esto coincide con cómo otras variantes de `EXPLAIN` aceptan sus opciones).
Si no hay índices hipotéticos definidos para la tabla, `EXPLAIN WHATIF` informa `status: not_applicable` con una sugerencia para crear uno.
**Fila combinada (múltiples candidatos)**
Cuando dos o más candidatos se evalúan empíricamente, `EXPLAIN WHATIF` agrega un bloque adicional llamado `(combined: idx_a, idx_b, ...)` después de las filas de cada candidato. Informa del beneficio conjunto de tener *todos* esos índices a la vez: una lectura real conserva un gránulo solo si sobrevive a *todos* los índices de omisión, por lo que la estimación combinada es la intersección de los gránulos supervivientes de los candidatos. Por tanto, su `skip_ratio` es al menos tan alta como la del mejor candidato individual: los índices complementarios podan más juntos, mientras que los redundantes la dejan sin cambios.
Solo contribuyen los candidatos con `source: empirical`, porque la fila combinada se construye al intersectar sus conjuntos de supervivencia por gránulo. Los candidatos estimados como `statistical` o `applicability_only` no tienen datos por gránulo y se excluyen; en consecuencia, el bloque combinado aparece solo cuando al menos dos candidatos produjeron una estimación empírica y, en caso contrario, se omite (por ejemplo, con `empirical = 0`). Sus campos de estimación se leen igual que los de un bloque empírico por candidato, excepto que `elapsed_us` es `0` — la estimación combinada se deriva de los escaneos por candidato, no de un escaneo nuevo. El nombre sintético `(combined: ...)` es solo una etiqueta del informe y no puede usarse con `force_data_skipping_indices`.
**Ejemplo empírico**
```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
```
El `minmax` hipotético podaría de 100 marcas a 1 — `skip_ratio: 99.0%`. (`est_bytes` es una estimación basada en el tamaño promedio de la fila, por lo que la cifra exacta puede variar.)
**Ejemplo estadístico**
Las [estadísticas de columna](/docs/es/reference/engines/table-engines/mergetree-family/mergetree#column-statistics) están desactivadas de forma predeterminada. Para usar la ruta `statistical`, defínalas primero en las columnas correspondientes y espere a que finalice la mutación de materialización:
```sql theme={null}
ALTER TABLE t ADD STATISTICS b TYPE TDigest;
ALTER TABLE t MATERIALIZE STATISTICS b SETTINGS mutations_sync = 1;
```
Luego, deshabilite el método empírico para que el estimador vuelva a usar las estadísticas de columna:
```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
```
El número proviene de la selectividad de las estadísticas de columna para `b < 10` (aproximadamente 10 filas de 10000) y se muestra como un límite superior de `skip_ratio`. No hay `sampled_parts` / `sampled_marks`: no se leyó ningún dato.
Si ninguna de las dos vías está disponible (p. ej., `empirical = 0` y no hay estadísticas de columna definidas), el estimador informa `source: applicability_only` y un `skip_ratio: 0.0%` conservador.
### EXPLAIN TABLE OVERRIDE
Muestra el resultado de una sobrescritura de tabla aplicada al esquema de una tabla a la que se accede mediante una función de tabla.
También realiza ciertas validaciones y genera una excepción si la sobrescritura hubiera provocado algún tipo de fallo.
**Ejemplo**
Suponga que tiene una tabla MySQL remota como esta:
```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) │
└─────────────────────────────────────────────────────────┘
```
La validación aún no es exhaustiva, por lo que una consulta correcta no garantiza que la sobrescritura no vaya a causar problemas.