DataFusion 中逻辑计划反序列化问题分析：LEFT ANTI/SEMI JOIN 的 SQL 生成问题

在 Apache DataFusion 项目中，当使用逻辑计划反序列化功能将包含 LEFT ANTI JOIN 或 LEFT SEMI JOIN 操作符的逻辑计划转换为 SQL 时，生成的 SQL 语句在某些数据库方言中会出现兼容性问题。这个问题尤其在使用 PostgreSQL、MySQL 或 SQLite 等数据库方言时表现明显。

问题背景

DataFusion 是一个用 Rust 编写的查询引擎，它提供了将逻辑计划转换为 SQL 语句的功能。在优化查询计划时，系统可能会将某些操作（如 NOT IN 子查询）转换为 LEFT ANTI JOIN 这种更高效的执行方式。然而，当需要将这些优化后的逻辑计划重新转换为 SQL 语句时，特别是在跨数据库联邦查询场景下，生成的 SQL 可能会不符合目标数据库的语法规范。

问题表现

具体来说，当逻辑计划中包含：

1. LEFT ANTI JOIN（左反连接）操作符时，反序列化会生成包含"LEFT ANTI JOIN"的 SQL 语句
2. LEFT SEMI JOIN（左半连接）操作符时，反序列化会生成包含"LEFT SEMI JOIN"的 SQL 语句

这些语法结构在 PostgreSQL、MySQL 和 SQLite 等主流数据库中并不支持，导致生成的 SQL 无法在这些数据库上执行。

技术分析

从技术实现角度看，这个问题涉及几个关键层面：

1. 逻辑计划优化：查询优化器将 NOT IN 子查询等结构转换为更高效的 JOIN 操作是常见的优化手段
2. SQL 反序列化：将优化后的逻辑计划转换回 SQL 时，需要考虑到目标数据库的语法支持
3. 方言适配：不同数据库系统对 JOIN 类型的支持程度不同，需要针对不同方言做适配

解决方案探讨

针对这个问题，可以考虑以下几种解决方案方向：

1. 方言感知的反序列化：在反序列化时，根据目标数据库方言将特殊的 JOIN 类型转换为该方言支持的等价形式

   • 例如将 LEFT ANTI JOIN 转换为 NOT EXISTS 或 NOT IN 子查询
   • 将 LEFT SEMI JOIN 转换为 EXISTS 或 IN 子查询

2. 优化器配置：提供选项控制优化器是否生成这些特殊 JOIN 类型，特别是在需要反序列化为特定方言 SQL 的场景

3. 下游处理：将方言适配的责任转移到使用 DataFusion 的上层应用中

从项目历史看，之前已有类似问题的修复记录（PR #10625），这表明这个问题可能需要更系统性的解决方案，而不仅仅是针对特定情况的修补。

影响范围

这个问题特别影响以下使用场景：

1. 联邦查询：在 DataFusion 中查询外部数据库时
2. SQL 生成：需要将 DataFusion 逻辑计划转换为特定数据库可执行的 SQL 时
3. 查询调试：当开发者需要查看优化后的 SQL 形式时

总结

DataFusion 中逻辑计划反序列化生成的 SQL 与目标数据库方言的兼容性问题，特别是在处理特殊 JOIN 类型时，需要更全面的解决方案。这个问题不仅关系到功能的正确性，也影响着系统的跨数据库兼容能力。理想的解决方案应当能够在保持查询语义不变的前提下，生成符合目标数据库语法的 SQL 语句。