TiDB多表连接查询中列缺失问题的分析与解决

问题背景

在TiDB数据库系统中，当执行包含多个表连接的复杂查询时，从v8.5.0版本开始出现了一个"Can't find column"的错误。这个问题特别容易在包含多个JOIN操作和窗口函数的复杂查询中出现。

问题现象

用户报告在执行如下类型的SQL查询时会出现错误：

CREATE TABLE t1(a INT, b INT, c INT, d INT, e INT);
CREATE TABLE t2(a INT, b INT, c INT, d INT, e INT);
CREATE TABLE t3(a INT, b INT, c INT, d INT, e INT);
CREATE TABLE t4(a INT, b INT, c INT, d INT, e INT);
CREATE TABLE t5(a INT, b INT, c INT, d INT, e INT);

EXPLAIN SELECT tmp4.b 
FROM t1 
JOIN t2 ON t1.a = t2.b 
JOIN t3 ON t1.b = t3.b 
LEFT JOIN (
    SELECT a, b, c, (ROW_NUMBER() OVER (PARTITION BY b ORDER BY e ASC)) 
    FROM t4
) tmp4 ON tmp4.b = t2.c AND tmp4.c = t3.c 
JOIN t5 ON t5.a = t1.e;

执行上述查询时，系统会返回错误："ERROR 1105 (HY000): Can't find column test.t4.b in schema Column: [] Unique key: []"。

技术分析

问题根源

这个问题源于TiDB查询优化器中的两个关键组件之间的交互问题：

1. **投影消除(Projection Elimination)**优化规则
2. **列剪枝(Column Pruning)**优化过程

详细机制

在查询优化过程中，系统会执行多个优化步骤：

1. 投影消除阶段：

   • 当处理JOIN操作时，如果其子节点被消除，系统会重建该JOIN操作的schema
   • 在这个过程中，列的UniqueID可能会发生变化（例如t4.b从28变为20）
   • 但问题在于，系统只更新了JOIN操作的schema，而没有同步更新其FullSchema

2. 列剪枝阶段：

   • 父JOIN操作在剪枝时会检查每个需要的列来自哪个子节点
   • 在v8.5.0版本后，当子节点是JOIN操作时，系统会使用FullSchema而非schema来进行检查
   • 由于FullSchema未更新，导致系统无法正确识别某些列（如t4.b）的来源

3. 错误产生：

   • 经过优化后，JOIN操作不再包含必要的列（如t4.b）
   • 但顶层的投影操作仍然需要这些列
   • 最终在ResolveIndices阶段，系统无法找到所需的列，从而报错

解决方案

该问题已被修复，主要解决思路是：

1. 确保在投影消除优化后，同时更新JOIN操作的schema和FullSchema
2. 保持两个schema中列的UniqueID一致性
3. 确保列剪枝阶段能够正确识别所有需要的列

影响范围

该问题影响以下TiDB版本：

• v8.5.0
• v9.0.0-beta.1

更早版本不受此问题影响。用户如果遇到类似问题，建议升级到已修复该问题的版本。

总结

这个案例展示了数据库查询优化器中不同优化阶段之间复杂的交互关系。在TiDB这样的分布式数据库中，查询优化器的正确性对查询执行至关重要。通过深入分析优化器内部机制，开发团队能够准确定位并修复这类复杂问题，确保系统稳定性和查询正确性。