```
Uma junção externa gera uma linha de saída preenchida com `NULL` para cada linha de um lado preservado que não encontrou correspondência. Essas linhas são subtraídas para não diluírem a razão. Apenas um lado preservado as tem — o lado direito em `RIGHT` e `FULL`, e o esquerdo em `LEFT` e `FULL`:
* `fanout = 0` — as linhas correspondentes não produziram nenhuma linha de saída, como ocorre em uma junção `ANTI`: ela gera apenas as linhas que não encontraram correspondência.
* `fanout = 1` — uma junção 1:1 sem duplicações; cada linha correspondente produziu exatamente uma linha de saída.
* `fanout > 1` — uma junção 1:N; chaves duplicadas do outro lado multiplicaram as linhas. Um valor alto nos dois lados ao mesmo tempo é sinal de uma explosão cartesiana não intencional.
#### Quando os números exigem `matches = 1`
A maioria desses números decorre dos dados que a junção já gera e é informada por um simples `EXPLAIN ANALYZE`. Os demais exigem uma contabilização que a junção não faria de outra forma e, por isso, só são informados com `EXPLAIN ANALYZE matches = 1`. Quais são eles depende do algoritmo; na família hash, há dois casos:
* o lado **direito** de `ALL INNER` e `ALL LEFT`, que exige marcar todas as linhas correspondentes do lado direito;
* o lado **esquerdo** de `ALL LEFT` e `ALL FULL`, mas somente quando a consulta não seleciona nada da
tabela à direita e a seção `ON` é uma simples igualdade de chave. Caso contrário, a sondagem já registra
quais linhas do lado esquerdo tiveram correspondência — seja para materializar as colunas do lado direito ou para avaliar a condição
residual — e a contagem é exata sem a opção.
`partial_merge` precisa disso para o lado **direito** dos quatro tipos `ALL`, pelo mesmo motivo.
`full_sorting_merge` e `parallel_full_sorting_merge` precisam disso para **ambos** os lados dos tipos `ANY`. Os
tipos `ALL` não precisam de nada.
A opção fica desativada por padrão porque a contabilização adicional tem custo, e não usá-la reduz a fidelidade da medição. O trabalho é realizado dentro do loop de sondagem e aumenta com o número de linhas de saída. Use `matches = 1` quando precisar saber as correspondências exatas encontradas pelas linhas dos lados esquerdo e direito.
`matches = 1` não torna todas as combinações passíveis de coleta. Os lados que uma junção pode informar decorrem do que ela já precisa fazer de qualquer forma; portanto, isso depende tanto do algoritmo quanto do tipo e da strictness.
**Família hash.** `hash`, `parallel_hash` e `grace_hash` sempre se comportam da mesma forma:
| Junção | `matched` esquerdo | `matched` direito |
| ------------------------------------------------ | ------------------ | ----------------- |
| `ALL INNER`, `ALL LEFT`, `ALL RIGHT`, `ALL FULL` | sim | sim |
| `SEMI LEFT`, `ANTI LEFT` | sim | não |
| `ANY RIGHT`, `ANTI RIGHT` | não | sim |
| `ASOF` (interna) | sim | não |
| `SEMI RIGHT` | não | não |
| `ANY INNER`, `ANY LEFT`, `ASOF LEFT` | não | não |
O lado direito não está disponível sempre que a junção mantém apenas uma linha por chave em sua tabela hash, como fazem as junções `ANY`, `SEMI` e `ANTI`: as linhas duplicadas do lado direito nunca são armazenadas e, portanto, não podem ser contadas. O lado esquerdo não está disponível quando a junção suprime a saída de uma linha do lado esquerdo cuja correspondente já foi reivindicada por outra linha desse lado, fazendo com que as linhas emitidas sejam uma subcontagem das linhas com correspondência.
Ativar [`any_join_distinct_right_table_keys`](/pt-BR/reference/settings/session-settings/other#any_join_distinct_right_table_keys) muda `ANY` para a semântica mais antiga `RightAny`, que emite uma linha por linha do lado esquerdo e, portanto, mantém ambas as contagens. `ANY RIGHT` e `ANY FULL` passam a informar **ambos** os lados, e `ANY INNER` é reescrito como `SEMI LEFT`.
O motor de tabela [`Join`](/pt-BR/reference/engines/table-engines/special/join) segue a mesma tabela, usando o tipo e a strictness declarados no mecanismo: `Join(ALL, INNER, …)` informa ambos os lados, enquanto `Join(ANY, LEFT, …)` não informa nenhum deles.
**Algoritmos de merge.** `full_sorting_merge` e `parallel_full_sorting_merge` aceitam os quatro tipos `ALL`, `ANY INNER`, `ANY LEFT`, `ANY RIGHT`, `ASOF` e `ASOF LEFT`. Eles informam **ambos** os lados para todos os tipos, exceto `ASOF` e `ASOF LEFT`, nos quais o lado direito é `not collected`, mesmo sem `matches = 1` — eles percorrem as duas entradas ordenadas e veem todas as linhas de uma faixa de valores iguais à medida que as consomem, portanto nada precisa ser reconstruído posteriormente.
`partial_merge` aceita `ALL INNER`, `ALL LEFT`, `ALL RIGHT`, `ALL FULL`, `ANY INNER`, `ANY LEFT` e `SEMI LEFT`. Ele informa ambos os lados para os quatro tipos `ALL`, sendo o direito com `matches = 1`; para `ANY INNER`, `ANY LEFT` e `SEMI LEFT`, o lado direito é `not collected`.
**`direct`.** Somente o lado esquerdo. O lado direito é um armazenamento de chave-valor que nunca é materializado em linhas e, portanto, não possui nenhuma linha `Right:`.
**`CROSS`, `COMMA` e um `ON` constante.** Nenhum dos lados, conforme descrito [acima](#explain-analyze-join-algorithm-lines).
Quando ambos os algoritmos informam um número, os resultados coincidem. Os algoritmos de mesclagem simplesmente têm mais informações; eles não divergem quanto ao que constitui uma correspondência.
#### Linhas específicas do algoritmo
Vejamos as linhas adicionais incluídas por cada implementação de junção.
Para as junções `hash` e `parallel_hash` e para o motor de tabela `Join`, uma linha `Hash table:` descreve a tabela hash criada a partir da tabela à direita:
```txt theme={null}
Hash table: unique keys · memory
```
* `unique keys ` — o número de chaves únicas armazenadas na tabela hash durante a fase de compilação.
* `memory ` — o pico de memória usado pela tabela hash durante a fase de compilação.
Para a junção `grace_hash`, a linha `Hash table:` também informa como a junção se adaptou ao limite de memória, e uma linha `Spill:` informa se os dados foram gravados em disco:
```txt theme={null}
Hash table: unique keys · memory · buckets · rehashes
Spill: yes · left spilled · right spilled
```
* `buckets ` — o número de buckets que a junção grace hash teve ao final da execução. Esse número é sempre uma potência de `2`.
* `rehashes ` — quantas vezes o número de buckets precisou ser dobrado para se ajustar ao limite de memória.
* `Spill:` — uma flag `yes`/`no` que indica se houve spill para disco. Quando houve, `left spilled ` e `right spilled ` informam os bytes comprimidos gravados em disco dos lados esquerdo (probe) e direito (build); quando não houve spill, a linha é simplesmente `Spill: no`.
Na junção `partial_merge`, a linha `Right:` contém informações adicionais sobre como a tabela da direita foi armazenada em buffer e ordenada, e o tempo de ordenação é exibido nas linhas `Stage (build)` e `Stage (probe)`:
```txt theme={null}
Right: rows · matched · size · blocks · storage · match rate % · fanout
Stage (build): time (%) · parallelism / · sort time · sort share %
Stage (probe): time (%) · parallelism / · sort time · sort share %
```
* `size ` — o tamanho em memória dos blocos da tabela à direita.
* `blocks ` — o número de blocos nos quais a tabela à direita foi armazenada em buffer.
* `storage ` — indica se a tabela à direita coube na memória (`in-memory`) ou precisou ser descarregada em disco (`external`). Quando é `external`, um campo adicional `spilled ` informa os bytes comprimidos gravados em disco.
* `sort time ` — o tempo gasto na ordenação da tabela à direita (no estágio de compilação) e de cada bloco recebido da esquerda (no estágio de sondagem).
* `sort share %` — `sort time` como proporção do *tempo de ocupação do próprio estágio* (a soma do tempo decorrido de seus processadores), diferentemente da porcentagem de `time` do estágio, que representa uma proporção do *tempo de execução de toda a consulta*.
Para a junção `full_sorting_merge`, são impressas apenas as linhas comuns `Left:` e `Right:`.
Para a junção `direct`, é impressa apenas a linha `Left:`, pois o lado direito é um armazenamento de chave-valor consultado diretamente, em vez de ser materializado em linhas.
Para uma junção `CROSS` ou `COMMA`, e para qualquer seção `ON` sem igualdade de chave, uma linha `Buffer:` descreve como a tabela à direita foi mantida na memória, e uma linha `Spill:` informa se ela foi descarregada em disco:
```txt theme={null}
Buffer: memory · compressed
Spill: yes · right spilled
```
* `memory ` — o pico de memória ocupado pela tabela da direita armazenada em buffer.
* `compressed ` — indica se pelo menos um bloco armazenado em buffer foi comprimido; nesse caso, os leitores descompactam todos os blocos armazenados.
* `Spill:` — a mesma flag `yes`/`no` de `grace_hash`, com `right spilled ` informando os bytes comprimidos gravados em disco.
Ambos os lados informam `matched not collected` aqui: um predicado constante associa todas as linhas da esquerda a todas as linhas da direita ou a nenhuma delas; portanto, não é possível determinar quais linhas individuais corresponderam.
Para uma junção com o motor de tabela [`Join`](/pt-BR/reference/engines/table-engines/special/join), ambos os lados são informados, juntamente com a linha `Hash table:`, que descreve a tabela pré-criada. O lado direito contabiliza as linhas armazenadas no mecanismo, não as linhas de uma compilação específica da consulta.
#### Tempos por processador
Com `processors = 1`, uma linha extra é impressa abaixo de cada estágio, mostrando a distribuição do tempo decorrido entre os processadores do estágio:
```txt theme={null}
Time per processor (): min · median · max · sum
```
`` é o número de processadores no estágio. Uma grande diferença entre `median` e `max` indica um desequilíbrio de carga entre processadores paralelos.
### EXPLAIN ESTIMATE
Mostra o número estimado de linhas, marcas e partes que serão lidas das tabelas durante o processamento da consulta. Funciona com tabelas da família [MergeTree](/pt-BR/reference/engines/table-engines/mergetree-family/mergetree).
**Exemplo**
Criando uma tabela:
```sql title="Query" theme={null}
CREATE TABLE ttt (i Int64) ENGINE = MergeTree() ORDER BY i SETTINGS index_granularity = 16, write_final_mark = 0;
INSERT INTO ttt SELECT number FROM numbers(128);
OPTIMIZE TABLE ttt;
```
```sql title="Query" theme={null}
EXPLAIN ESTIMATE SELECT * FROM ttt;
```
```text title="Response" theme={null}
┌─database─┬─table─┬─parts─┬─rows─┬─marks─┐
│ default │ ttt │ 1 │ 128 │ 8 │
└──────────┴───────┴───────┴──────┴───────┘
```
### EXPLAIN WHATIF
Estima o benefício que um skip index hipotético teria em uma consulta `SELECT`, *sem* materializar o índice em disco. Defina um ou mais candidatos com [`CREATE HYPOTHETICAL INDEX`](/pt-BR/reference/statements/hypothetical-index#create-hypothetical-index) e, em seguida, execute `EXPLAIN WHATIF SELECT ...` para ver, para cada candidato: aplicabilidade, marcas lidas estimadas, bytes estimados e taxa de descarte.
**Sintaxe**
```sql theme={null}
EXPLAIN WHATIF [empirical = 0] SELECT ...
```
**Configurações**
* `empirical` — `1` (padrão) executa o índice em memória sobre os grânulos filtrados pela referência para medir a taxa de descarte (um limite superior). `0` ignora esse caminho. De qualquer forma, se `empirical` não produzir um resultado (por estar desabilitado ou porque o índice não pode ser avaliado em memória), o estimador recorre às [estatísticas](/pt-BR/reference/engines/table-engines/mergetree-family/mergetree#column-statistics) da coluna e, por fim, a um resumo apenas de aplicabilidade se nenhuma das duas opções estiver disponível.
**Saída**
```text theme={null}
Baseline (after PK + partition + existing indexes):
table: db.t
parts: 1
marks: 100
est_bytes: 1.50 MiB (only when the query reads rows)
With idx_b (minmax, hypothetical):
status: applicable
marks: 1
est_bytes: 15.00 KiB (only when baseline bytes are known)
skip_ratio: 99.0%
Estimation:
source: empirical | statistical | applicability_only
empirical_status: ok | unsupported | disabled
sampled_parts: 50 / 100 (only when source = empirical)
sampled_marks: 50 / 100 (only when source = empirical)
elapsed_us: 631 (only when source = empirical)
```
* `source` — como a estimativa foi gerada.
* `empirical`: construiu o índice em memória sobre os grânulos remanescentes após o pruning de referência e contou os grânulos que o índice pularia. Este é um limite superior — veja as limitações em [`CREATE HYPOTHETICAL INDEX`](/pt-BR/reference/statements/hypothetical-index#limitations).
* `statistical`: derivado de estatísticas de coluna. Usado quando a estimativa empírica está desabilitada (`empirical = 0`) ou não conseguiu produzir um resultado, e há estatísticas de coluna definidas nas colunas relevantes.
* `applicability_only`: o índice é aplicável ao predicado, mas nem a estimativa empírica nem a estatística produziram um resultado (por exemplo, `empirical = 0` e nenhuma estatística de coluna definida). Informa `skip_ratio: 0.0%` como um limite conservador.
* `sampled_parts` / `sampled_marks` — ` / `. Mostra que fração da tabela restou após o pruning por PK, partição e índices existentes, ou seja, a entrada para o índice hipotético.
* `est_bytes` — uma estimativa dos bytes lidos, derivada do tamanho médio de linha da tabela; por isso, é aproximada e varia conforme o armazenamento e a compressão. A linha de referência aparece apenas quando a consulta lê linhas; a linha de cada candidato, apenas quando a estimativa de bytes da linha de referência é conhecida.
A configuração é escrita inline entre `WHATIF` e `SELECT` — não há palavra-chave `SETTINGS` (isso corresponde à forma como outras variantes de `EXPLAIN` aceitam suas opções).
Se nenhum índice hipotético estiver definido para a tabela, `EXPLAIN WHATIF` informa `status: not_applicable` com uma dica para criar um.
**Linha combinada (múltiplos candidatos)**
Quando dois ou mais candidatos são avaliados empiricamente, `EXPLAIN WHATIF` acrescenta um bloco extra chamado `(combined: idx_a, idx_b, ...)` após as linhas de cada candidato. Ele informa o benefício conjunto de ter *todos* esses índices ao mesmo tempo: uma leitura real mantém um grânulo apenas se ele sobreviver a *todos* os skip indexes, portanto a estimativa combinada é a interseção dos grânulos sobreviventes dos candidatos. Seu `skip_ratio` é, portanto, pelo menos tão alto quanto o do melhor candidato individual — índices complementares fazem mais pruning em conjunto, enquanto índices redundantes o mantêm inalterado.
Só contribuem os candidatos com `source: empirical`, porque a linha combinada é formada pela interseção dos conjuntos de sobrevivência por grânulo de cada um. Os candidatos estimados como `statistical` ou `applicability_only` não têm dados por grânulo e são excluídos; consequentemente, o bloco combinado aparece somente quando pelo menos dois candidatos produziram uma estimativa empírica, e é omitido caso contrário (por exemplo, com `empirical = 0`). Seus campos de estimativa são os mesmos de um bloco empírico por candidato, exceto que `elapsed_us` é `0` — a estimativa combinada é derivada das varreduras por candidato, não de uma nova varredura. O nome sintético `(combined: ...)` é apenas um rótulo do relatório e não pode ser usado com `force_data_skipping_indices`.
**Exemplo 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
```
O `minmax` hipotético reduziria de 100 marcas para 1 — `skip_ratio: 99.0%`. (`est_bytes` é uma estimativa com base no tamanho médio da linha, portanto o valor exato varia.)
**Exemplo estatístico**
As [estatísticas](/pt-BR/reference/engines/table-engines/mergetree-family/mergetree#column-statistics) de coluna vêm desativadas por padrão. Para usar o caminho `statistical`, primeiro defina-as nas colunas relevantes e aguarde a conclusão da mutação de materialização:
```sql theme={null}
ALTER TABLE t ADD STATISTICS b TYPE TDigest;
ALTER TABLE t MATERIALIZE STATISTICS b SETTINGS mutations_sync = 1;
```
Em seguida, desative o caminho empírico para que o estimador passe a usar as estatísticas de coluna:
```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
```
O número vem da seletividade das estatísticas da coluna de `b < 10` (cerca de 10 linhas em 10000) e é informado como um limite superior de `skip_ratio`. Não há `sampled_parts` / `sampled_marks` — nenhum dado foi lido.
Se nenhum dos dois caminhos estiver disponível (por exemplo, `empirical = 0` e nenhuma estatística de coluna definida), o estimador informa `source: applicability_only` e um `skip_ratio: 0.0%` conservador.
### EXPLAIN TABLE OVERRIDE
Mostra o resultado de um override de tabela em um esquema acessado por meio de uma função de tabela.
Também faz algumas validações, gerando uma exceção se o override causar algum tipo de falha.
**Exemplo**
Suponha que você tenha uma tabela 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) │
└─────────────────────────────────────────────────────────┘
```
A validação não está completa, portanto uma consulta bem-sucedida não garante que o override não cause problemas.