标签： 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 的全局优化。

✅ 目标与收益