TiDB中PhysicalExchangeSender的HashCols浅拷贝问题解析

问题背景

在TiDB的MPP查询执行过程中，PhysicalExchangeSender负责数据在不同节点间的分发工作。其中HashCols属性用于指定哈希分区时使用的列信息，这些列决定了数据如何分布到不同节点上。然而，在TiDB v5.2版本引入的一个改动中，HashCols的处理存在一个潜在的严重问题。

问题本质

问题的核心在于PhysicalExchangeSender的ResolveIndicesItself方法中，对HashCols的处理采用了浅拷贝而非深拷贝。具体表现为：

1. 当处理HashCols数组中的每个元素时，只对Col字段进行了深拷贝
2. 整个HashCols[i]对象本身没有被重新构造
3. 导致多个PhysicalExchangeSender共享相同的HashCols引用

这种实现方式违反了MPP查询执行的基本假设，即每个ExchangeSender应该有自己独立的HashCols配置。

问题触发条件

这个bug相对隐蔽，需要满足以下条件才会触发：

1. 查询计划中包含多个分区连接操作
2. 连接键的数量大于1
3. 多个连接使用相同的列作为连接键
4. 这些连接键在不同表中具有不同的数据类型(否则不会产生额外的ExchangeSender)

问题影响

一旦触发，可能导致两种严重后果：

1. TiFlash节点崩溃
2. MPP查询返回错误结果

这两种情况都会严重影响生产环境的稳定性和查询结果的正确性。

问题复现

通过以下步骤可以复现该问题：

1. 创建三张包含不同类型但相同名称列的表
2. 启用TiFlash副本
3. 设置相关参数强制使用MPP执行计划
4. 执行包含多表连接的查询

在多次执行后，可能会遇到TiFlash节点崩溃或返回错误结果的情况。

技术分析

问题的根本原因在于对象共享与修改的冲突。当多个PhysicalExchangeSender共享相同的HashCols引用时，后续的修改会覆盖之前的配置，导致：

1. 哈希分区列信息被错误覆盖
2. 数据分发策略与预期不符
3. 可能引发类型系统不一致的问题

这种问题在分布式查询执行中尤为危险，因为它可能导致数据被分发到错误的节点，进而产生错误的结果或系统不稳定。

解决方案

正确的实现应该对HashCols进行完全的深拷贝，包括：

1. 创建新的HashCols数组
2. 对数组中的每个元素进行完整拷贝
3. 确保所有相关属性都被正确复制

这样可以保证每个PhysicalExchangeSender都有自己独立的HashCols配置，避免共享引用带来的问题。

总结

这个案例展示了在分布式数据库系统中，即使是看似微小的实现细节(如浅拷贝与深拷贝的选择)也可能导致严重的系统级问题。特别是在查询执行计划生成阶段，必须确保所有物理操作符的配置都是独立且完整的，以避免执行时的意外行为。对于TiDB用户来说，如果遇到MPP查询返回错误结果或TiFlash节点不稳定情况，应考虑此问题的可能性。