`. Indique quelle fraction de la table reste après l’élagage par la PK, la partition et les index existants, c.-à-d. l’entrée de l’index hypothétique.
* `est_bytes` — estimation du nombre d’octets lus, dérivée de la taille moyenne des lignes de la table ; elle est donc approximative et varie selon le stockage et la compression. La ligne de référence n’apparaît que lorsque la requête lit des lignes ; la ligne par candidat n’apparaît que lorsque l’estimation de référence des octets est connue.
Le paramètre est écrit en intégré entre `WHATIF` et `SELECT` — il n’y a pas de mot-clé `SETTINGS` (comme pour les autres variantes de `EXPLAIN`, qui acceptent leurs options de cette manière).
Si aucun index hypothétique n’est défini pour la table, `EXPLAIN WHATIF` indique `status: not_applicable` avec une suggestion d’en créer un.
**Ligne combinée (plusieurs candidats)**
Lorsque deux candidats ou plus sont évalués empiriquement, `EXPLAIN WHATIF` ajoute un bloc supplémentaire nommé `(combined: idx_a, idx_b, ...)` après les lignes par candidat. Il indique le bénéfice combiné de la présence simultanée de *tous* ces index : lors d’une lecture réelle, un granule n’est conservé que s’il survit à *chaque* skip index, donc l’estimation combinée correspond à l’intersection des granules survivants des candidats. Son `skip_ratio` est donc au moins aussi élevé que celui du meilleur candidat pris isolément — des index complémentaires élaguent davantage ensemble, tandis que des index redondants le laissent inchangé.
Seuls les candidats avec `source: empirical` contribuent, car la ligne combinée est construite en intersectant leurs ensembles de survie par granule. Les candidats estimés comme `statistical` ou `applicability_only` n’ont pas de données par granule et sont exclus ; par conséquent, le bloc combiné n’apparaît que lorsqu’au moins deux candidats ont produit une estimation empirique, et il est omis dans le cas contraire (par exemple avec `empirical = 0`). Les champs de son estimation sont les mêmes que pour un bloc empirique par candidat, à ceci près que `elapsed_us` vaut `0` — l’estimation combinée est dérivée des analyses par candidat, et non d’une nouvelle analyse. Le nom synthétique `(combined: ...)` n’est qu’une étiquette de rapport et ne peut pas être utilisé avec `force_data_skipping_indices`.
**Exemple empirique**
```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
```
Le `minmax` hypothétique réduirait 100 marks à 1 — `skip_ratio: 99.0%`. (`est_bytes` est une estimation basée sur la taille moyenne des lignes, donc la valeur exacte peut varier.)
**Exemple statistique**
Les [statistiques de colonne](/docs/fr/reference/engines/table-engines/mergetree-family/mergetree#column-statistics) sont désactivées par défaut. Pour utiliser le chemin `statistical`, définissez-les d’abord sur les colonnes concernées, puis attendez que la mutation de matérialisation se termine :
```sql theme={null}
ALTER TABLE t ADD STATISTICS b TYPE TDigest;
ALTER TABLE t MATERIALIZE STATISTICS b SETTINGS mutations_sync = 1;
```
Désactivez ensuite le chemin empirique afin que l’estimateur revienne aux statistiques de colonne :
```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
```
Le nombre provient de la sélectivité des statistiques de colonne pour `b < 10` (environ 10 lignes sur 10 000) et est indiqué comme borne supérieure de `skip_ratio`. Il n’y a ni `sampled_parts` ni `sampled_marks` — aucune donnée n’a été lue.
Si aucun des deux mécanismes n’est disponible (par ex. `empirical = 0` et aucune statistique de colonne définie), l’estimateur indique `source: applicability_only` ainsi qu’un `skip_ratio: 0.0%` conservateur.
### EXPLAIN TABLE OVERRIDE
Affiche le résultat d'une surcharge de table appliquée au schéma d'une table accessible via une fonction de table.
Effectue également certaines vérifications et lève une exception si la surcharge aurait entraîné un échec.
**Exemple**
Supposons que vous ayez une table MySQL distante comme celle-ci :
```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 validation n'est pas exhaustive ; une requête réussie ne garantit donc pas que l'override ne posera pas de problèmes.