```
外部結合では、相手が見つからなかった保持側の各行に対して、`NULL` で埋められた出力行が 1 行生成されます。これらの行は比率を薄めないよう差し引かれます。このような行が存在するのは保持側のみです。`RIGHT` と `FULL` では右側、`LEFT` と `FULL` では左側になります。
* `fanout = 0` — 一致した行からは出力行がまったく生成されません。これは `ANTI` join の動作であり、相手が見つからなかった行のみを出力します。
* `fanout = 1` — 明確な 1:1 join です。一致した各行から、ちょうど 1 行の出力行が生成されます。
* `fanout > 1` — 1:N join です。もう一方の側の重複キーによって行数が増加しました。両側で同時に大きな値になる場合は、意図しない Cartesian 的な行数の急増を示します。
#### 数値に `matches = 1` が必要な場合
これらの数値の大半は、結合がいずれにせよ構築するデータから得られるため、通常の `EXPLAIN ANALYZE` で報告されます。残りは、結合が通常は行わない追跡処理を必要とするため、`EXPLAIN ANALYZE matches = 1` でのみ報告されます。どれが該当するかはアルゴリズムによって異なり、hash ファミリーでは次の 2 つです。
* 一致したすべての右行に印を付ける必要がある、`ALL INNER` と `ALL LEFT` の**右**側。
* `ALL LEFT` と `ALL FULL` の**左**側。ただし、クエリが右テーブルから何も選択せず、
`ON` セクションが単純なキーの等価条件である場合に限ります。それ以外の場合、プローブはすでに
一致した左行を記録します。これは右カラムをマテリアライズするため、または残余条件を評価するためです。
そのため、このオプションがなくてもカウントは正確です。
`partial_merge` では、同じ理由で 4 種類の `ALL` の**右**側に必要です。
`full_sorting_merge` と `parallel_full_sorting_merge` では、`ANY` 種類の**両方**の側に必要です。
`ALL` 種類では何も必要ありません。
追加の追跡処理にはコストがかかり、計測精度に影響します。そのため、このオプションはデフォルトで無効になっています。処理はプローブループ内で実行され、出力行数に応じて増加します。左行と右行が相手側で正確に何件一致したかを知る必要がある場合は、`matches = 1` を使用してください。
`matches = 1` を指定しても、すべての組み合わせで収集できるようになるわけではありません。結合がどちらの側を報告できるかは、その結合がいずれにせよ実行する必要がある処理によるため、種類や厳密性だけでなくアルゴリズムにも依存します。
**Hash ファミリー。** `hash`、`parallel_hash`、`grace_hash` は常に同じ結果になります。
| Join | `matched` 左 | `matched` 右 |
| ------------------------------------------------ | ----------- | ----------- |
| `ALL INNER`, `ALL LEFT`, `ALL RIGHT`, `ALL FULL` | はい | はい |
| `SEMI LEFT`, `ANTI LEFT` | はい | いいえ |
| `ANY RIGHT`, `ANTI RIGHT` | いいえ | はい |
| `ASOF` (inner) | はい | いいえ |
| `SEMI RIGHT` | いいえ | いいえ |
| `ANY INNER`, `ANY LEFT`, `ASOF LEFT` | いいえ | いいえ |
結合がハッシュテーブル内でキーごとに 1 行だけを保持する場合、右側は収集できません。これは `ANY`、`SEMI`、`ANTI` 結合で行われます。重複する右行は保存されないため、カウントできません。別の左行によってすでに相手が確保されている左行の出力を結合が抑制する場合、左側は収集できません。この場合、出力される行数は一致した行数より少なくなります。
[`any_join_distinct_right_table_keys`](/ja/reference/settings/session-settings/other#any_join_distinct_right_table_keys) を有効にすると、`ANY` は以前の `RightAny` セマンティクスに切り替わります。このセマンティクスでは左行ごとに 1 行が出力されるため、両方のカウントが保持されます。その場合、`ANY RIGHT` と `ANY FULL` は**両方**の側を報告し、`ANY INNER` は `SEMI LEFT` に書き換えられます。
[`Join`](/ja/reference/engines/table-engines/special/join) テーブルエンジンも同じ表に従い、エンジンで宣言された種類と厳密性を使用します。`Join(ALL, INNER, …)` は両方の側を報告し、`Join(ANY, LEFT, …)` はどちらも報告しません。
**マージアルゴリズム。** `full_sorting_merge` と `parallel_full_sorting_merge` は、4 種類の `ALL`、`ANY INNER`、`ANY LEFT`、`ANY RIGHT`、`ASOF`、`ASOF LEFT` を受け入れます。`ASOF` と `ASOF LEFT` を除くすべての種類で**両方**の側を報告します。これらでは右側が `not collected` になります。また、`matches = 1` も不要です。2 つのソート済み入力を走査し、処理中に等しい範囲にあるすべての行を確認するため、後から再構築する必要がないからです。
`partial_merge` は `ALL INNER`、`ALL LEFT`、`ALL RIGHT`、`ALL FULL`、`ANY INNER`、`ANY LEFT`、`SEMI LEFT` を受け入れます。4 種類の `ALL` では両方の側を報告しますが、右側には `matches = 1` が必要です。`ANY INNER`、`ANY LEFT`、`SEMI LEFT` では右側が `not collected` になります。
**`direct`。** 左側のみです。右側は行としてマテリアライズされないキー・バリューストアであるため、`Right:` 行自体がありません。
**`CROSS`、`COMMA`、定数の `ON`。** [前述](#explain-analyze-join-algorithm-lines)のとおり、どちらの側も報告されません。
両方のアルゴリズムが数値を報告する場合、その値は一致します。マージアルゴリズムは単により多くの情報を持っているだけで、何を一致とみなすかについて見解が異なるわけではありません。
#### アルゴリズム固有の行
各JOIN実装がこれに加えて出力する行を見てみましょう。
`hash` および `parallel_hash` JOIN、ならびに `Join` テーブルエンジンでは、`Hash table:` 行に右テーブルから構築されたハッシュテーブルの情報が表示されます。
```txt theme={null}
Hash table: unique keys · memory
```
* `unique keys ` — ビルドフェーズ中にハッシュテーブルに格納された一意のキーの数。
* `memory ` — ビルドフェーズ中にハッシュテーブルが使用したピークメモリ。
`grace_hash` join では、`Hash table:` 行に、join がメモリ制限にどのように適応したかも表示されます。また、`Spill:` 行には、データがディスクにスピルされたかどうかが表示されます。
```txt theme={null}
Hash table: unique keys · memory · buckets · rehashes
Spill: yes · left spilled · right spilled
```
* `buckets ` — 実行終了時点で Grace Hash Join に含まれるバケット数です。常に `2` のべき乗になります。
* `rehashes ` — メモリ制限内に収めるために、バケット数を 2 倍にする必要があった回数です。
* `Spill:` — ディスクへのスピリングが発生したかどうかを示す `yes`/`no` フラグです。発生した場合、`left spilled ` と `right spilled ` は、それぞれ左側 (probe) と右側 (build) でスピリングされた圧縮バイト数を示します。スピリングが発生しなかった場合、この行は単に `Spill: no` となります。
`partial_merge` 結合では、`Right:` 行に右テーブルのバッファリング方法とソート方法に関する追加情報が含まれ、ソート時間は `Stage (build)` 行と `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 ` — 右テーブルのブロックのメモリ使用量。
* `blocks ` — 右テーブルがバッファリングされたブロック数。
* `storage ` — 右テーブルがメモリに収まったか (`in-memory`) 、またはディスクにスピルする必要があったか (`external`) 。`external` の場合、追加の `spilled ` にディスクに書き込まれた圧縮バイト数が表示されます。
* `sort time ` — 右テーブルのソート (build ステージ) と、受信した各左ブロックのソート (probe ステージ) に費やされた時間。
* `sort share %` — ステージの `time` の割合が*クエリ全体の実行時間*に占める割合であるのに対し、`sort time` が*そのステージ自体のビジー時間* (各プロセッサの経過時間の合計) に占める割合。
`full_sorting_merge` join では、共通の `Left:` 行と `Right:` 行のみが出力されます。
`direct` join では、右側は行としてマテリアライズされず直接ルックアップされるキー・バリューストアであるため、`Left:` 行のみが出力されます。
`CROSS` または `COMMA` join、およびキーの等価条件を含まない任意の `ON` セクションでは、`Buffer:` 行に右テーブルがメモリ内でどのように保持されたかが示され、`Spill:` 行にディスクにスピルされたかどうかが表示されます。
```txt theme={null}
Buffer: memory · compressed
Spill: yes · right spilled
```
* `memory ` — バッファリングされた右テーブルが使用したピークメモリ。
* `compressed ` — バッファリングされたブロックが少なくとも1つ圧縮されているかどうか。圧縮されている場合、reader は保存されているすべてのブロックを展開します。
* `Spill:` — `grace_hash` と同じ `yes`/`no` フラグで、`right spilled ` はディスクに書き込まれた圧縮バイト数を示します。
ここでは両側で `matched not collected` が報告されます。定数の predicate では、すべての左行がすべての右行と組み合わされるか、まったく組み合わされないかのいずれかとなるため、個々のどの行が一致したかを特定することはできません。
[`Join`](/ja/reference/engines/table-engines/special/join) テーブルエンジンとの join では、事前構築済みテーブルを説明する `Hash table:` 行とともに、両側が報告されます。右側では、クエリごとの build の行数ではなく、エンジンに格納されている行数がカウントされます。
#### プロセッサごとの時間
`processors = 1` の場合、各ステージの下に追加の行が出力され、そのステージのプロセッサごとの経過時間の分布が表示されます。
```txt theme={null}
Time per processor (): min · median · max · sum
```
`` はそのステージのプロセッサ数です。`median` と `max` の間に大きなギャップがある場合は、並列プロセッサ間で負荷に偏りがあることを示します。
### EXPLAIN ESTIMATE
クエリの実行時に、テーブルから読み取られると推定される行数、マーク数、パーツ数を表示します。[MergeTree](/ja/reference/engines/table-engines/mergetree-family/mergetree) ファミリーのテーブルで使用できます。
**例**
テーブルを作成します。
```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
仮想的なスキップ索引をディスク上に*マテリアライズ*することなく、それが `SELECT` クエリにもたらす効果を見積もります。[`CREATE HYPOTHETICAL INDEX`](/ja/reference/statements/hypothetical-index#create-hypothetical-index) で 1 つ以上の候補を定義し、`EXPLAIN WHATIF SELECT ...` を実行すると、各候補について、適用可否、推定読み取りマーク数、推定バイト数、スキップ率を確認できます。
**構文**
```sql theme={null}
EXPLAIN WHATIF [empirical = 0] SELECT ...
```
**設定**
* `empirical` — `1` (デフォルト) では、スキップ率 (上限値) を測定するため、ベースラインで絞り込まれたグラニュールに対してメモリ内で索引を適用します。`0` ではその処理をスキップします。いずれの場合も、`empirical` で結果が得られない場合 (無効になっている、または索引をメモリ内で評価できない場合) 、推定器はカラム [STATISTICS](/ja/reference/engines/table-engines/mergetree-family/mergetree#column-statistics) にフォールバックし、それも利用できなければ、最終的に適用可否のみのサマリーにフォールバックします。
**出力**
```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` — 推定値の算出方法を示します。
* `empirical`: ベースラインで pruned されたグラニュールを対象に、メモリ内で索引を構築し、その索引によってスキップされるグラニュール数を数えます。これは上限値です。制限事項については [`CREATE HYPOTHETICAL INDEX`](/ja/reference/statements/hypothetical-index#limitations) を参照してください。
* `statistical`: カラム STATISTICS から導出されます。empirical が無効化されている場合 (`empirical = 0`) 、または empirical で結果を生成できず、かつ関連するカラムにカラム STATISTICS が定義されている場合に使用されます。
* `applicability_only`: 索引は predicate に適用可能ですが、empirical と statistical のいずれでも結果を生成できなかったことを示します (たとえば `empirical = 0` でカラム STATISTICS が定義されていない場合) 。保守的な上限として `skip_ratio: 0.0%` を返します。
* `sampled_parts` / `sampled_marks` — ` / `。テーブル全体のうち、PK、partition、既存の索引による pruning を通過した割合、つまり仮想索引への入力となる部分を示します。
* `est_bytes` — 読み取られるバイト数の推定値です。テーブルの平均行サイズから導出されるため概算であり、ストレージや圧縮によって変動します。ベースラインの行はクエリが行を読み取る場合にのみ表示され、候補ごとの行はベースラインのバイト推定値がわかっている場合にのみ表示されます。
この設定は `WHATIF` と `SELECT` の間にインラインで記述します。`SETTINGS` キーワードはありません (これは、他の `EXPLAIN` バリアントでオプションを受け付ける方法と一致しています) 。
テーブルに仮想索引が定義されていない場合、`EXPLAIN WHATIF` は `status: not_applicable` を返し、作成を促すヒントを表示します。
**結合行 (複数候補)**
2 つ以上の候補が empirical で評価されると、`EXPLAIN WHATIF` は候補ごとの行の後に `(combined: idx_a, idx_b, ...)` という名前の追加ブロックを 1 つ付加します。これは、それらすべての索引を同時に持つ場合の総合的な効果を示します。実際の読み取りでは、あるグラニュールが保持されるのは、それが *すべて* のスキップ索引を通過した場合だけなので、結合推定値は各候補で生き残るグラニュールの積集合になります。したがって、この `skip_ratio` は少なくとも最良の単一候補と同等以上になります。相補的な索引は組み合わせることでより多くを prune し、冗長な索引では変化しません。
寄与するのは `source: empirical` の候補だけです。これは、結合された行が各 グラニュール ごとの生存集合の積集合を取って構築されるためです。`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` は平均行サイズに基づく推定値のため、正確な値は変動します。)
**統計の例**
[カラム STATISTICS](/ja/reference/engines/table-engines/mergetree-family/mergetree#column-statistics)はデフォルトで無効になっています。`statistical` パスを試すには、まず対象のカラムでこれらを定義し、materialize mutation が完了するまで待ちます:
```sql theme={null}
ALTER TABLE t ADD STATISTICS b TYPE TDigest;
ALTER TABLE t MATERIALIZE STATISTICS b SETTINGS mutations_sync = 1;
```
次に、推定器がカラム STATISTICS を使用するよう、経験則ベースのパスを無効にします：
```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` のカラム STATISTICS における選択性 (10000 行中およそ 10 行) に基づくもので、`skip_ratio` の上限として報告されます。`sampled_parts` / `sampled_marks` はなく、データは読み取られていません。
どちらの方法も利用できない場合 (たとえば `empirical = 0` で、かつカラム STATISTICS が定義されていない場合) 、推定器は `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) │
└─────────────────────────────────────────────────────────┘
```
検証は完全ではないため、クエリが成功しても、そのオーバーライドが問題を引き起こさないことは保証されません。