本文将从底层原理和源代码的角度详细解释 ClickHouse 多表 JOIN 的处理过程，尽量用通俗移动的语言，让初学者也能理解。本文会分步骤推导，涵盖 JOIN 的原理、实现方式、关键代码逻辑以及优化机制，同时确保逻辑清晰、内容全面。最后给出具体的优化方法
1. 什么是 JOIN 以及 ClickHouse 中的 JOIN
1.1 JOIN 的基本概念
在数据库中，JOIN 是一种操作，用于将多个表的数据根据某些条件（通常是键值匹配）合并在一起，形成一个结果集。例如：
- 有两张表：users（存储用户ID和姓名）和 orders（存储订单ID和用户ID）。
- 我们想查询每个用户的订单信息，就需要通过 user_id 将两张表“连接”起来。
常见的 JOIN 类型包括：
- INNER JOIN：只返回两表中匹配的行。
- LEFT JOIN：保留左表所有行，右表匹配不到的用 NULL 填充。
- RIGHT JOIN：保留右表所有行，左表匹配不到的用 NULL 填充。
- FULL JOIN：保留两表所有行，匹配不到的用 NULL 填充。
- CROSS JOIN：两表行的笛卡尔积（每行与每行组合）。
ClickHouse 支持以上 JOIN 类型，但它的 JOIN 实现有自己的特点，因为 ClickHouse 是一个列式存储的分析型数据库，优化目标是高性能、大数据量处理。
1.2 ClickHouse JOIN 的特点
ClickHouse 的 JOIN 有以下关键特性：
- 列式存储：ClickHouse 按列存储数据，JOIN 操作需要处理列之间的匹配，而不是传统的行式数据库那样逐行处理。
- 分布式处理：ClickHouse 通常运行在集群上，JOIN 可能涉及跨节点的分布式计算。
- 内存优化：ClickHouse 倾向于将 JOIN 的右表（通常是较小的表）加载到内存中，以加速匹配。
- 多种 JOIN 算法：ClickHouse 支持多种 JOIN 算法（如 Hash Join、Merge Join），根据数据大小和分布选择最优算法。
- 严格的语法限制：ClickHouse 的 JOIN 语法要求右表明确指定，且不支持复杂的子查询作为 JOIN 表。
2. ClickHouse 多表 JOIN 的底层原理
为了让初学者理解，我们先从概念入手，逐步深入到代码层面。
2.1 JOIN 的核心步骤
无论是什么类型的 JOIN，其核心步骤可以简化为：
- 读取数据：从左表和右表读取需要 JOIN 的列。
- 匹配键：根据 JOIN 条件（通常是
ON子句中的键）找到匹配的行。 - 合并结果：根据 JOIN 类型（INNER、LEFT 等）构造结果集。
- 优化执行：通过索引、内存管理、并行处理等优化性能。
在 ClickHouse 中，这些步骤被分解为更细粒度的操作，结合列式存储和分布式架构。
2.2 列式存储对 JOIN 的影响
传统行式数据库（如 MySQL）存储数据时，每行是一个完整的记录，JOIN 时直接比较整行。ClickHouse 是列式存储，数据按列组织，例如：
- users 表可能有两列：user_id 和 name，分别存储在不同的文件中。
- JOIN 时，ClickHouse 只加载 user_id 和 JOIN 所需的列，而不是整个表。
这带来两个优势：
- 减少 I/O：只需要读取 JOIN 相关的列，节省磁盘和内存开销。
- 向量化执行：ClickHouse 可以批量处理列数据，利用 CPU 的向量化指令（SIMD）加速计算。
2.3 JOIN 算法
ClickHouse 主要使用以下 JOIN 算法：
- Hash Join：
- 将右表（通常较小）加载到内存，构建一个哈希表，键是 JOIN 条件中的字段。
- 遍历左表的数据，用哈希表快速查找匹配的行。
- 适用于右表较小、内存足够的情况。
- Merge Join：
- 要求两表的 JOIN 键已排序。
- 类似“拉链”式合并，逐行比较两表的键。
- 适合大数据量且键已排序的场景。
- Nested Loop Join：
- 对左表的每行，扫描右表的每一行，检查是否匹配。
- 效率低，仅在特殊场景（如小表或无法使用哈希表）使用。
ClickHouse 默认优先选择 Hash Join，因为它在内存充足时性能最高。以下是 Hash Join 的伪代码：
// 构建右表的哈希表
HashMap<key, row> hash_table;
for each row in right_table:
key = row[join_key];
hash_table[key].append(row);
// 遍历左表，查找匹配
for each row in left_table:
key = row[join_key];
if hash_table.contains(key):
for each matched_row in hash_table[key]:
output(row, matched_row);
3. ClickHouse 多表 JOIN 的执行流程
我们以一个具体的例子，详细推导 ClickHouse 如何处理多表 JOIN。假设有以下查询：
SELECT u.name, o.order_id
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id
INNER JOIN payments p ON o.order_id = p.order_id;
这个查询涉及三表：users、orders 和 payments，通过 user_id 和 order_id 进行连接。
3.1 解析查询
ClickHouse 首先解析 SQL，生成一个抽象语法树（AST）。在 AST 中，JOIN 被表示为一个操作节点，包含：
- 左表和右表的引用。
- JOIN 类型（这里是 INNER JOIN）。
- JOIN 条件（u.user_id = o.user_id 和 o.order_id = p.order_id）。
解析后的 AST 会交给查询优化器，优化器会：
- 确定 JOIN 的执行顺序（例如，先 users 和 orders 连接，再和 payments 连接）。
- 选择合适的 JOIN 算法（通常是 Hash Join）。
- 决定哪些列需要读取。
3.2 确定 JOIN 顺序
多表 JOIN 需要决定执行顺序。ClickHouse 的优化器会根据以下因素选择顺序：
- 表的大小：优先将小表作为右表，加载到内存。
- 统计信息：ClickHouse 可能利用表的统计数据（如行数、数据分布）估算代价。
- JOIN 条件：确保 JOIN 键的高选择性（即匹配的行数较少）。
在上面的例子中，假设 users 有 1000 万行，orders 有 5000 万行，payments 有 2000 万行。优化器可能选择：
- 先执行 users 和 orders 的 JOIN，因为 users 较小，可以作为右表加载到内存。
- 再将结果与 payments 连接。
优化后的执行计划可能是：
(users INNER JOIN orders) INNER JOIN payments
3.3 读取数据
ClickHouse 按列读取数据。对于查询：
SELECT u.name, o.order_id
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id
INNER JOIN payments p ON o.order_id = p.order_id;
需要读取的列是：
- users：user_id（JOIN 键）、name（输出）。
- orders：user_id（JOIN 键）、order_id（JOIN 键和输出）。
- payments：order_id（JOIN 键）。
ClickHouse 使用存储引擎（如 MergeTree）读取这些列。读取过程：
- 根据表的元数据，找到存储 user_id、name 等列的文件。
- 利用索引（如果有配置）跳过无关的数据块。
- 将数据加载到内存，准备 JOIN。
3.4 执行 JOIN
我们以 users 和 orders 的 JOIN 为例，假设使用 Hash Join：
构建哈希表：
- ClickHouse 读取 orders 表的 user_id 和 order_id 列。
- 为每行计算 user_id 的哈希值，存储到哈希表中。
- 哈希表的键是 user_id，值是对应的 order_id 列表。
- 代码逻辑（简化伪）：
HashMap<UInt64, Vector<Row>> hash_table; for each row in orders: key = row["user_id"]; hash_table[key].push_back(row);
探测阶段：
- 读取 users 表的 user_id 和 name 列。
- 对每行的 user_id，在哈希表中查找匹配的 orders 行。
- 如果找到匹配（INNER JOIN），将 users 的 name 和 orders 的 order_id 合并到结果集中。
- 代码逻辑（简化伪）：
for each row in users: key = row["user_id"]; if hash_table.contains(key): for each matched_row in hash_table[key]: result.append({row["name"], matched_row["order_id"]});
处理下一个 JOIN：
- 上述 JOIN 的结果（users 和 orders 的匹配行）作为左表。
- 再与 payments 表执行类似的 Hash Join，匹配 order_id。
3.5 输出结果
JOIN 完成后，ClickHouse 将结果集（包含 name 和 order_id）返回给客户端。结果集仍然按列存储，传输时会序列化为客户端请求的格式（如 JSON、CSV）。
4. 源代码层面的实现
ClickHouse 是开源的，我们可以参考其源代码（基于 GitHub 上的 ClickHouse 仓库）来理解 JOIN 的实现。以下是关键代码路径和逻辑的概述：
4.1 JOIN 操作的核心类
ClickHouse 的 JOIN 实现在以下模块中：
- src/Interpreters/Join.h 和 Join.cpp：定义了 JOIN 操作的接口和实现。
- src/Interpreters/HashJoin.h 和 HashJoin.cpp：实现了 Hash Join 算法。
- src/Storages/StorageJoin.h 和 StorageJoin.cpp：处理特殊的 JOIN 表（预加载到内存的表）。
核心类是 IJoin，它是一个抽象接口，定义了 JOIN 的行为：
class IJoin
{
public:
virtual ~IJoin() = default;
virtual bool addBlockToJoin(const Block & block, bool check_limits = true) = 0;
virtual void joinBlock(Block & block) = 0;
// 其他方法...
};
HashJoin 是 IJoin 的具体实现，用于执行 Hash Join。
4.2 Hash Join 的实现
HashJoin 类的核心逻辑：
构建哈希表：
- 方法：addBlockToJoin。
- 功能：将右表的数据加载到内存，构建哈希表。
- 关键代码（简化）：
void HashJoin::addBlockToJoin(const Block & block, bool /*check_limits*/) { for (const auto & column : block) { // 根据 JOIN 键提取列数据 auto key = column.column->getPtr(); // 插入哈希表 hash_table.insert(key, column); } }
探测阶段：
- 方法：joinBlock。
- 功能：遍历左表的数据，在哈希表中查找匹配。
- 关键代码（简化）：
void HashJoin::joinBlock(Block & block) { for (size_t i = 0; i < block.rows(); ++i) { // 提取左表的 JOIN 键 auto key = block.getByPosition(key_position).column->get64(i); // 查找哈希表 if (auto matched = hash_table.find(key)) { // 构造结果行 appendMatchedRows(block, matched); } } }
4.3 多表 JOIN 的处理
多表 JOIN 在 InterpreterSelectQuery 类中被分解为多个双表 JOIN。代码路径：
- src/Interpreters/InterpreterSelectQuery.cpp：解析查询并生成执行计划。
- src/Interpreters/ExpressionAnalyzer.cpp：优化 JOIN 顺序。
优化器会将多表 JOIN 转换为一系列双表 JOIN，例如：
// 伪代码
auto join1 = executeJoin(users, orders, INNER, "user_id = user_id");
auto join2 = executeJoin(join1, payments, INNER, "order_id = order_id");
4.4 分布式 JOIN
如果数据分布在多个节点，ClickHouse 会：
- 将右表广播到所有节点（如果右表较小）。
- 在每个节点上并行执行 JOIN。
- 合并结果。
分布式 JOIN 的逻辑在 src/Interpreters/DistributedStages/PlanSegmentExecutor.cpp 中实现。
5. 优化机制
ClickHouse 在 JOIN 过程中使用了多种优化手段：
- 索引利用：如果表有主键或二级索引，ClickHouse 会用索引过滤数据，减少扫描量。
- 内存管理：哈希表使用高效的内存分配器（如 jemalloc），避免内存碎片。
- 并行处理：JOIN 操作可以分配到多个 CPU 核心并行执行。
- 数据压缩：列式存储的数据通常是压缩的，读取时解压，减少 I/O。
- 右表预加载：对于小表，ClickHouse 支持 StorageJoin 引擎，将右表预加载到内存，加速 JOIN。
6. 例子比喻的总结
用简单的比喻解释 ClickHouse 的多表 JOIN：
- 想象你有三本账本：users（记录客户姓名和 ID）、orders（记录订单和客户 ID）、payments（记录付款和订单 ID）。
- 你想找出每个客户的订单和付款信息：
- 先把 orders 账本整理成一本“索引簿”，按客户 ID 分类（这就是哈希表）。
- 拿着 users 账本，逐个客户 ID 去索引簿里找对应的订单，写下匹配的结果。
- 再把这个结果当作一本新账本，和 payments 账本做类似的匹配。
- ClickHouse 就像一个超级聪明的会计，它只看需要的页面（列），用最快的索引方式（哈希表），还能让多个助手（CPU 核心）一起干活。
7. 注意事项和限制
- 右表大小：Hash Join 要求右表能装进内存。如果右表太大，可能导致内存溢出。
- JOIN 顺序：ClickHouse 的优化器可能不总是选择最优顺序，复杂查询需要手动调整。
- 分布式 JOIN 的开销：广播右表会增加网络开销，需权衡数据分布。
- 语法限制：ClickHouse 不支持动态右表（如子查询），需提前物化。
8. 结论
ClickHouse 的多表 JOIN 通过列式存储、Hash Join 算法和分布式处理实现了高性能。其核心步骤包括解析查询、优化执行计划、读取列数据、构建哈希表、匹配和合并结果。源代码层面，HashJoin 和 InterpreterSelectQuery 类实现了核心逻辑，结合内存管理和并行优化，确保高效执行。
下面就讲述多表join的优化策略
ClickHouse 的 JOIN 性能可能因数据规模、查询模式、硬件环境或配置不当而表现不佳。以下是从底层原理、配置优化、查询设计和硬件角度，详细讲解如何优化 ClickHouse JOIN 性能，达到最快速度。
1. 理解 JOIN 性能瓶颈
在优化之前，先识别 JOIN 性能差的可能原因：
- 数据量大：右表过大导致内存溢出，或左表扫描量过多。
- JOIN 算法选择不当：默认的 Hash Join 在某些场景（如右表过大）效率低。
- I/O 开销：读取无关列或数据块过多。
- 分布式开销：跨节点广播右表或数据 shuffle 耗时。
- 硬件限制：内存不足、CPU 核心数少或磁盘 I/O 慢。
优化目标是：减少内存使用、降低 I/O、加速匹配、优化分布式执行。
2. 优化 JOIN 性能的具体方法
以下是分步骤的优化策略，从查询设计到系统配置，逐一推导原因并提供实现方法。
2.1 查询设计优化
2.1.1 选择合适的 JOIN 类型
- 原理：不同的 JOIN 类型（如 INNER、LEFT、RIGHT）影响结果集大小和计算复杂度。INNER JOIN 只保留匹配行，通常比 LEFT 或 FULL JOIN 更快。
- 优化方法：
- 优先使用 INNER JOIN，避免不必要的 LEFT 或 FULL JOIN。
- 如果必须用 LEFT JOIN，确保右表尽可能小。
- 示例：
-- 低效：LEFT JOIN 保留所有左表行 SELECT u.name, o.order_id FROM users u LEFT JOIN orders o ON u.user_id = o.user_id; -- 优化：如果只需要匹配的行，用 INNER JOIN SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id;
2.1.2 减少 JOIN 表的数据量
- 原理：JOIN 前通过 WHERE 子句或子查询过滤数据，减少扫描和匹配的行数。
- 优化方法：
- 在 JOIN 前对左表和右表应用 WHERE 条件，过滤无关行。
- 使用子查询或物化视图预先聚合数据。
- 示例：
-- 低效：JOIN 后再过滤 SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id WHERE o.order_date = '2025-05-01'; -- 优化：JOIN 前过滤 SELECT u.name, o.order_id FROM (SELECT * FROM users WHERE active = 1) u INNER JOIN (SELECT * FROM orders WHERE order_date = '2025-05-01') o ON u.user_id = o.user_id;
2.1.3 优化 JOIN 键
- 原理：JOIN 键的选择性（即唯一值的比例）影响匹配效率。高选择性的键（接近唯一）减少哈希表碰撞，加速查找。
- 优化方法：
- 选择高选择性的 JOIN 键（如主键或唯一索引）。
- 确保 JOIN 键类型简单（如整数而非字符串），减少比较开销。
- 示例：
-- 低效：用字符串作为 JOIN 键 SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.email = o.customer_email; -- 优化：用整数 user_id SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id;
2.1.4 使用物化视图或 StorageJoin
- 原理：ClickHouse 支持 StorageJoin 引擎，将右表预加载到内存，构建持久化的哈希表，适合频繁 JOIN 的小表。物化视图可预聚合数据，减少 JOIN 时的数据量。
- 优化方法：
- 对于小表（几 MB 到几 GB），创建 StorageJoin 表。
- 对于大表，创建物化视图预聚合。
- 示例：
-- 创建 StorageJoin 表 CREATE TABLE orders_join ENGINE = Join(ANY, INNER, user_id) AS SELECT user_id, order_id FROM orders; -- 查询时直接使用 SELECT u.name, o.order_id FROM users u INNER JOIN orders_join o ON u.user_id = o.user_id;
2.1.5 控制 JOIN 顺序
- 原理：ClickHouse 优化器可能无法选择最优的 JOIN 顺序。手动指定顺序可减少中间结果集大小。
- 优化方法：
- 将小表放在 JOIN 的早期，减少后续 JOIN 的数据量。
- 使用括号明确指定 JOIN 顺序。
- 示例：
-- 低效：优化器可能先处理大表 SELECT u.name, o.order_id, p.payment_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id INNER JOIN payments p ON o.order_id = p.order_id; -- 优化：明确小表优先 SELECT u.name, o.order_id, p.payment_id FROM (users u INNER JOIN orders o ON u.user_id = o.user_id) INNER JOIN payments p ON o.order_id = p.order_id;
2.2 配置优化
2.2.1 调整 JOIN 算法
- 原理：ClickHouse 默认使用 Hash Join，但某些场景下其他算法（如 Merge Join）更优。可以通过配置强制指定算法。
- 优化方法：
- 对于已排序的大表，启用 Merge Join（需设置 join_algorithm = 'merge'）。
- 对于内存不足的情况，启用部分内存 JOIN（partial_merge_join）。
- 示例：
-- 强制使用 Merge Join SET join_algorithm = 'merge'; SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id;
2.2.2 增加内存限制
- 原理：Hash Join 需要将右表加载到内存，内存不足会导致溢出到磁盘，性能下降。
- 优化方法：
- 增加 max_bytes_before_external_join 参数，允许更大内存用于 JOIN。
- 确保服务器有足够物理内存。
- 示例：
-- 增加 JOIN 内存限制 SET max_bytes_before_external_join = 1000000000; -- 1GB
2.2.3 启用并行处理
- 原理：ClickHouse 支持多线程执行 JOIN，增加线程数可加速处理。
- 优化方法：
- 设置 max_threads 参数，分配更多 CPU 核心。
- 确保 max_parallel_replicas 启用，允许分布式并行。
- 示例：
SET max_threads = 16; SET max_parallel_replicas = 4;
2.3 表设计优化
2.3.1 添加索引
- 原理：ClickHouse 的 MergeTree 引擎支持主键和二级索引，JOIN 前可通过索引快速过滤数据。
- 优化方法：
- 在 JOIN 键上创建主键或
ORDER BY键。 - 添加
DATA SKIPPING INDEX跳过无关数据块。
- 在 JOIN 键上创建主键或
- 示例：
-- 创建带主键的表 CREATE TABLE orders ( user_id UInt32, order_id UInt64, order_date Date ) ENGINE = MergeTree() ORDER BY (user_id, order_date); -- 添加跳跃索引 ALTER TABLE orders ADD INDEX idx_user_id user_id TYPE minmax GRANULARITY 8192;
2.3.2 优化表分区
- 原理：分区可以减少 JOIN 时扫描的数据量，尤其对时间序列数据有效。
- 优化方法：
- 按 JOIN 键或时间字段分区。
- 在查询中指定分区条件。
- 示例：
-- 创建分区表 CREATE TABLE orders ( user_id UInt32, order_id UInt64, order_date Date ) ENGINE = MergeTree() PARTITION BY toYYYYMM(order_date) ORDER BY (user_id); -- 查询指定分区 SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id WHERE o.order_date = '2025-05-01';
2.4 分布式优化
2.4.1 避免广播大表
- 原理：分布式 JOIN 默认广播右表到所有节点，大表广播会导致网络瓶颈。
- 优化方法：
- 确保右表较小（通过 WHERE 或子查询过滤）。
- 使用
GLOBAL JOIN控制分布式行为。
- 示例：
-- 使用 GLOBAL JOIN SELECT u.name, o.order_id FROM users u GLOBAL INNER JOIN orders o ON u.user_id = o.user_id;
2.4.2 数据本地化
- 原理：如果左表和右表的数据在同一节点上，JOIN 无需跨节点传输。
- 优化方法：
- 在建表时按 JOIN 键分片（
DISTRIBUTED BY）。 - 使用
Distributed引擎合理分布数据。
- 在建表时按 JOIN 键分片（
- 示例：
-- 按 user_id 分片 CREATE TABLE orders_dist ( user_id UInt32, order_id UInt64 ) ENGINE = Distributed(cluster, db, orders, user_id);
2.5 硬件优化
- 原理：ClickHouse 的 JOIN 性能受硬件限制，优化硬件可直接提升速度。
- 优化方法：
- 增加内存：确保右表能完全加载到内存（建议 64GB 或更高）。
- 使用 SSD：NVMe SSD 比 HDD 提供更快的 I/O。
- 更多 CPU 核心：支持更高并行度（建议 16 核以上）。
- 网络优化：分布式集群使用高带宽网络（10GbE 或更高）。
3. 性能优化的实际案例
以下低效查询：
SELECT u.name, o.order_id, p.payment_id
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id
INNER JOIN payments p ON o.order_id = p.order_id
WHERE o.order_date = '2025-05-01';
优化步骤：
- 改用 INNER JOIN：
SELECT u.name, o.order_id, p.payment_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id INNER JOIN payments p ON o.order_id = p.order_id WHERE o.order_date = '2025-05-01'; - 提前过滤：
SELECT u.name, o.order_id, p.payment_id FROM (SELECT * FROM users WHERE active = 1) u INNER JOIN (SELECT * FROM orders WHERE order_date = '2025-05-01') o ON u.user_id = o.user_id INNER JOIN payments p ON o.order_id = p.order_id; - 使用 StorageJoin：
CREATE TABLE payments_join ENGINE = Join(ANY, INNER, order_id) AS SELECT order_id, payment_id FROM payments; SELECT u.name, o.order_id, p.payment_id FROM (SELECT * FROM users WHERE active = 1) u INNER JOIN (SELECT * FROM orders WHERE order_date = '2025-05-01') o ON u.user_id = o.user_id INNER JOIN payments_join p ON o.order_id = p.order_id; - 配置并行和内存：
SET max_threads = 16; SET max_bytes_before_external_join = 2000000000; -- 2GB
4. 监控和调试
- 使用 EXPLAIN：查看 JOIN 的执行计划，确认算法和扫描量。
EXPLAIN PLAN SELECT u.name, o.order_id FROM users u INNER JOIN orders o ON u.user_id = o.user_id; - 检查系统表：分析查询性能瓶颈。
SELECT query_id, query_duration_ms, memory_usage FROM system.query_log WHERE query LIKE '%JOIN%'; - 启用日志：设置 log_queries = 1 记录详细日志，分析慢查询。
5 Patriarchal总结（比喻）
用比喻解释优化：
- JOIN 就像在图书馆找书：左表是你的书单，右表是书架上的书。
- 低效：你每次拿一本书（行），跑遍整个书架找匹配，累且慢。
- 优化：
- 先把书单精简（WHERE 过滤）。
- 把书架上的书编好索引（哈希表或 StorageJoin）。
- 派多个助手一起找（多线程）。
- 确保图书馆的路宽敞（高带宽网络）。
6. 注意事项
- 测试优化效果：每次调整后用小数据集验证性能提升。
- 避免过优化：如盲目增加内存可能导致其他查询受影响。
- 监控资源：优化后检查 CPU、内存和磁盘使用率，避免超载。
7. 结论
通过查询优化（过滤数据、选择 JOIN 类型、优化键）、配置调整（内存、线程、算法）、表设计（索引、分区）、分布式优化（本地化、避免广播）和硬件升级，ClickHouse 的 JOIN 性能可以显著提升。优先从查询设计入手（如提前过滤、使用 StorageJoin），再结合配置和硬件优化，逐步迭代直到达到最优性能。