Databend项目中UNION ALL查询导致MySQL客户端连接中断问题分析

问题现象

在Databend数据库系统中，用户通过MySQL客户端执行包含UNION ALL操作的嵌套查询时，出现了服务连接中断的异常情况。具体表现为执行类似SELECT a FROM (SELECT a, b FROM t1 WHERE a > 1 UNION ALL SELECT a, b FROM t1 WHERE b > 1)的查询语句后，MySQL客户端报错"Lost connection to MySQL server during query"。

技术背景

Databend是一个基于Rust构建的现代云原生数据仓库系统，采用MPP（大规模并行处理）架构。其查询执行引擎采用管道化处理模型，通过构建执行计划图（Pipeline Graph）来实现数据的高效处理。UNION ALL是SQL中常用的集合操作，用于合并多个查询结果集而不去重。

问题本质

从错误日志分析，该问题属于查询执行引擎的管道状态管理异常。错误信息显示"Pipeline graph is not finished"，表明执行计划中的某些节点未能正确完成状态转换。具体表现为：

1. 部分Transform节点（如UnionReceiveSink）处于"Processing"状态
2. 上游节点已标记为"Finished"但下游仍需要数据
3. 最终导致PullingExecutorSink节点因无法获取数据而处于"Idle"状态

这种状态不一致最终触发了系统的保护机制，主动终止了客户端连接。

影响范围

该问题特定出现在以下组合场景：

1. 使用MySQL协议客户端连接
2. 执行包含UNION ALL的嵌套查询
3. 查询中包含过滤条件（WHERE子句）
4. 特定版本的Databend服务端（如v1.2.674-nightly）

解决方案

根据技术讨论，该问题已在后续版本中得到修复。建议用户采取以下措施：

1. 升级到最新稳定版本（如v1.2.673-nightly及以上）
2. 对于暂时无法升级的环境，可考虑重写查询避免使用嵌套UNION ALL
3. 监控查询执行计划，关注Pipeline节点的状态转换

技术启示

该案例反映了分布式查询引擎中状态管理的重要性。在MPP架构中，执行节点的状态同步和错误处理需要特别关注：

1. 需要完善的超时机制处理卡死节点
2. 应建立更健壮的状态机转换验证
3. 客户端协议层需要更好的错误恢复能力

对于数据库开发者而言，这类问题的解决往往需要深入执行引擎内部，分析各处理阶段的状态流转，这也是现代数据库系统复杂性的典型体现。