```
外JOIN会为保留侧中每个未找到匹配行的行输出一个以 `NULL` 填充的结果行。这些行会被扣除，以免拉低该比率。只有保留侧会出现此类行——`RIGHT` 和 `FULL` 为右侧，`LEFT` 和 `FULL` 为左侧：
* `fanout = 0` — 匹配行完全没有产生结果行，这正是 `ANTI` JOIN的行为：它只输出未找到匹配行的行。
* `fanout = 1` — 完整的 1:1 JOIN；每个匹配行恰好产生一个结果行。
* `fanout > 1` — 1:N JOIN；另一侧的重复键导致行数倍增。两侧同时出现较大值，表明发生了非预期的 Cartesian 膨胀。
#### 何时需要 `matches = 1` 才能获取数值
这些数值大多来自 JOIN 本身就会生成的数据，普通的 `EXPLAIN ANALYZE` 即会报告。其余数值需要执行 JOIN 原本不会进行的额外记录操作，因此只有在使用 `EXPLAIN ANALYZE matches = 1` 时才会报告。具体哪些数值属于这种情况取决于算法；对于哈希家族，有以下两种情况：
* `ALL INNER` 和 `ALL LEFT` 的**右**侧，因为需要标记每个匹配的右侧行；
* `ALL LEFT` 和 `ALL FULL` 的**左**侧，但仅限于查询未从
右表选择任何内容，且 `ON` 子句只是简单的键相等条件时。否则，探测过程已经记录了
哪些左侧行匹配——无论是为了物化右侧列，还是为了评估剩余
条件——因此即使不使用该选项，计数也完全准确。
出于相同原因，`partial_merge` 对四种 `ALL` 类型的**右**侧需要此选项。
`full_sorting_merge` 和 `parallel_full_sorting_merge` 对 `ANY` 类型的**两**侧需要此选项。`ALL`
类型则无需额外操作。
该选项默认关闭，因为额外的记录操作并非没有成本，代价是测量保真度。相关工作在探测循环中完成，且会随输出行数增加而增长。需要准确了解左侧行和右侧行各自在另一侧找到多少匹配项时，请使用 `matches = 1`。
`matches = 1` 并不能让所有组合都可收集。JOIN 能报告哪一侧，取决于该 JOIN 本身必须执行哪些操作，因此既取决于算法，也取决于类型和严格性。
**哈希家族。** `hash`、`parallel_hash` 和 `grace_hash` 的行为始终一致：
| Join | 匹配的左侧 | 匹配的右侧 |
| ------------------------------------------------ | ----- | ----- |
| `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` | 否 | 否 |
当 JOIN 在哈希表中每个键只保留一行时，右侧便不可收集；`ANY`、`SEMI` 和 `ANTI` JOIN 正是如此：重复的右侧行从不存储，因此无法计数。当 JOIN 会抑制输出其匹配行已被另一个左侧行占用的左侧行时，左侧便不可收集，因为输出的行数会少于实际匹配的行数。
启用 [`any_join_distinct_right_table_keys`](/zh/reference/settings/session-settings/other#any_join_distinct_right_table_keys) 会将 `ANY` 切换为旧版 `RightAny` 语义，即每个左侧行输出一行，因此可保留两个计数。此时，`ANY RIGHT` 和 `ANY FULL` 会报告**两**侧，而 `ANY INNER` 会被重写为 `SEMI LEFT`。
[`Join`](/zh/reference/engines/table-engines/special/join) 表引擎遵循相同的表格规则，并使用引擎中声明的类型和严格性：`Join(ALL, INNER, …)` 报告两侧，`Join(ANY, LEFT, …)` 则两侧均不报告。
**合并算法。** `full_sorting_merge` 和 `parallel_full_sorting_merge` 支持四种 `ALL` 类型、`ANY INNER`、`ANY LEFT`、`ANY RIGHT`、`ASOF` 和 `ASOF LEFT`。除 `ASOF` 和 `ASOF LEFT` 外，它们会为每种类型报告**两**侧；对于后两者，右侧为 `not collected`，且无需 `matches = 1`——它们会遍历两个已排序的输入，并在处理相等范围时看到其中的每一行，因此之后无需重建任何信息。
`partial_merge` 支持 `ALL INNER`、`ALL LEFT`、`ALL RIGHT`、`ALL FULL`、`ANY INNER`、`ANY LEFT` 和 `SEMI LEFT`。它会为四种 `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 ` — 为满足内存限制而将桶数量翻倍的次数。
* `Spill:` — 一个 `yes`/`no` 标志，表示是否发生了落盘。若发生落盘，`left spilled ` 和 `right spilled ` 分别报告左侧 (probe) 和右侧 (build) 落盘的压缩字节数；若未发生落盘，该行即为 `Spill: no`。
对于 `partial_merge` JOIN，`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 ` — 对右表排序 (在构建阶段) 以及对每个传入的左块排序 (在探测阶段) 所花费的时间。
* `sort share %` — `sort time` 占*该阶段自身忙碌时间* (其处理器耗时之和) 的比例；不同于阶段 `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 ` — 是否至少有一个缓冲块经过压缩；读取器随后会解压所有已存储的块。
* `Spill:` — 与 `grace_hash` 相同的 `yes`/`no` 标志；`right spilled ` 则报告落盘的压缩字节数。
此处两侧均显示 `matched not collected`：常量谓词要么让每个左行与每个右行匹配，要么完全不匹配，因此无法确定具体哪些行发生了匹配。
对于与 [`Join`](/zh/reference/engines/table-engines/special/join) 表引擎进行的 JOIN，会同时报告两侧的信息，并附带描述预构建表的 `Hash table:` 行。右侧统计的是存储在引擎中的行数，而非某次查询中构建的行数。
#### 每个处理器的耗时
当 `processors = 1` 时，会在每个阶段下方额外打印一行，显示该阶段各处理器的耗时分布：
```txt theme={null}
Time per processor (): min · median · max · sum
```
`` 是该阶段中的处理器数量。`median` 和 `max` 之间差距较大，说明并行处理器之间存在负载不均。
### EXPLAIN ESTIMATE
显示在处理查询时，将从表中读取的预估行数、标记数和 parts 数量。适用于 [MergeTree](/zh/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`](/zh/reference/statements/hypothetical-index#create-hypothetical-index) 定义一个或多个候选项，然后运行 `EXPLAIN WHATIF SELECT ...`，即可查看每个候选项的以下信息：是否适用、预估读取的标记数、预估字节数以及跳过比率。
**语法**
```sql theme={null}
EXPLAIN WHATIF [empirical = 0] SELECT ...
```
**设置**
* `empirical` — `1` (默认值) 会在内存中对经过基线剪枝的粒度运行索引，以测量跳过比例 (上限) 。`0` 则会跳过该路径。无论哪种情况，如果 empirical 未产生结果 (已禁用，或索引无法在内存中求值) ，估算器都会回退到列[统计信息](/zh/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`：在内存中基于经过基线剪枝后的粒度构建索引，并统计该索引原本可以跳过的粒度数。这是一个上界——请参阅 [`CREATE HYPOTHETICAL INDEX`](/zh/reference/statements/hypothetical-index#limitations) 中的限制。
* `statistical`：根据列统计信息推导得出。当经验估算被禁用 (`empirical = 0`) ，或经验估算无法得出结果，且相关列已定义列统计信息时使用。
* `applicability_only`：该索引适用于该谓词，但经验估算和统计估算都未得出结果 (例如 `empirical = 0` 且未定义列统计信息) 。作为保守上界，会报告 `skip_ratio: 0.0%`。
* `sampled_parts` / `sampled_marks` — ` / `。显示在经过 PK、分区和现有索引剪枝后，表中有多少比例的数据被保留下来，即假设索引的输入。
* `est_bytes` — 读取字节数的估算值，由表的平均行大小推导而来，因此只是近似值，并会随存储和压缩情况而变化。只有当查询读取行时才会显示 baseline 行；只有在已知 baseline 字节估算值时，才会显示各候选项对应的行。
该设置以内联方式写在 `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` 是根据平均行大小估算得出的，因此具体数值会有所不同。)
**统计示例**
列[统计信息](/zh/reference/engines/table-engines/mergetree-family/mergetree#column-statistics)默认处于关闭状态。要触发 `statistical` 路径，请先在相关列上定义统计信息，然后等待物化变更完成：
```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` 的列统计信息选择性 (10000 行中约 10 行) ，并以 `skip_ratio` 上界的形式给出。不存在 `sampled_parts` / `sampled_marks`——未读取任何数据。
如果这两种路径都不可用 (例如 `empirical = 0` 且未定义列统计信息) ，估算器会报告 `source: applicability_only`，以及保守的 `skip_ratio: 0.0%`。
### EXPLAIN TABLE OVERRIDE
显示通过 table function 访问的表 schema 上应用表覆盖后的结果。
还会进行一些验证；如果该覆盖会导致某种失败，则会抛出异常。
**示例**
假设你有一个如下所示的远程 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) │
└─────────────────────────────────────────────────────────┘
```
验证并不完整，因此查询成功也不能保证该覆盖不会导致问题。