标签： Flink、Join 优化、Calcite、Query Planner、Batch Runtime
🧭 一、背景：Flink 在多表 Join 场景的瓶颈
在早期 Flink 版本（1.13 及之前），SQL 中的多表 Join 处理逻辑相对简单但低效。 其执行方式是 两两 Join 链式拼接（Binary Join Chain）：
A JOIN B JOIN C JOIN D → (((A JOIN B) JOIN C) JOIN D)这意味着每一次 Join 都需要生成中间结果、重新 Shuffle 数据、再参与下一层 Join。
在多表场景下，问题逐渐显现：
- ❌ 中间结果膨胀：每层 Join 都可能导致指数级中间数据量增长。
- ❌ 重复数据传输：每个阶段都要重新分区 Shuffle，浪费网络 IO。
- ❌ 优化受限：Calcite 优化器难以对跨多层的 Join 顺序、Join Key、Filter 提前下推。
- ❌ Planner 冗余复杂：两两 Join 的逻辑难以统一优化和复用。
于是，FLIP-516: MultiJoin support in the RelNode tree 正式提出并引入 Flink Planner。
🧩 二、FLIP-516 概述：从链式 Join 到多路 Join 的结构变革
FLIP-516 的核心思想是：
将多个连续的 Join 合并为一个统一的 MultiJoin 节点（RelNode），统一优化与下推。
它主要面向 批处理（Batch）SQL 规划器，以实现跨多表 Join 的全局优化。
✅ 目标与收益
| 优化方向 | 旧方案 (Binary Join) | 新方案 (MultiJoin) |
|---|---|---|
| Planner 层结构 |
