TiDB 中自然连接查询导致的列缺失错误分析

问题背景

在 TiDB 数据库系统中，当执行包含自然连接(NATURAL JOIN)和子查询的复杂 SQL 语句时，可能会遇到"Can't find column in schema"的错误。这类错误通常发生在查询优化器处理特定类型的连接操作时，特别是在涉及多表关联和聚合函数的场景中。

问题复现

通过以下简化后的 SQL 语句可以复现该问题：

CREATE TABLE mysql_3 (
    col_int_auto_increment INT(10) AUTO_INCREMENT,
    col_pk_char CHAR(60) NOT NULL,
    col_pk_date DATE NOT NULL,
    col_datetime DATETIME,
    col_int INT,
    col_date DATE,
    PRIMARY KEY (col_int_auto_increment, col_pk_char, col_datetime, col_int, col_date)
);

SELECT *
FROM mysql_3 t1
WHERE EXISTS
    (SELECT DISTINCT a1.*
     FROM mysql_3 a1
     WHERE (a1.col_pk_char NOT IN
              (SELECT a1.col_pk_char
               FROM mysql_3 a1 NATURAL
               RIGHT JOIN mysql_3 a2
               WHERE t1.col_pk_date IS NULL
               GROUP BY a1.col_pk_char)) )

执行上述查询时，TiDB 会报错："ERROR 1105 (HY000): Can't find column chqin.mysql_3.col_pk_char in schema Column: [] Unique key: []"。

问题原因分析

该问题的根本原因在于 TiDB 查询优化器在处理自然连接和聚合操作时的列解析逻辑存在缺陷。具体表现为：

1. 在自然连接操作中，系统会自动基于相同名称的列进行连接，这种隐式连接方式可能导致优化器在后续处理中无法正确追踪列来源。

2. 当自然连接与聚合函数(GROUP BY)结合使用时，优化器在构建执行计划时可能会丢失部分列信息，特别是在处理子查询中的列引用时。

3. 在错误信息中可以看到，系统无法在当前的 schema 中找到指定的列，这表明列解析阶段出现了问题，导致后续操作无法继续。

技术细节

深入分析该问题，主要涉及 TiDB 查询优化器的几个关键组件：

1. 逻辑优化阶段：在构建逻辑计划时，系统需要正确处理自然连接的语义，确保所有相关列都能被正确识别和保留。

2. 物理优化阶段：特别是在处理聚合操作时，basePhysicalAgg.ResolveIndices方法负责解析列索引，这里出现了列解析失败的情况。

3. 执行计划生成：系统在将逻辑计划转换为物理计划时，未能正确处理自然连接产生的中间结果集的列信息。

解决方案

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

1. 避免使用自然连接：改用显式的连接条件(如使用ON子句)可以避免这类隐式连接带来的问题。

2. 简化复杂查询：将复杂的嵌套查询拆分为多个简单查询，通过临时表或CTE(Common Table Expression)来分步处理。

3. 等待官方修复：该问题已被确认是TiDB的一个bug，可以关注后续版本更新中对该问题的修复。

最佳实践建议

对于TiDB用户，在处理复杂查询时建议：

1. 尽量避免使用自然连接语法，明确指定连接条件可以提高查询的可读性和稳定性。

2. 对于包含多层嵌套的子查询，考虑使用视图或临时表来简化查询结构。

3. 在升级TiDB版本时，注意测试包含复杂连接的查询语句，确保兼容性。

4. 遇到类似错误时，可以通过EXPLAIN命令分析查询执行计划，帮助定位问题所在。

总结

TiDB中自然连接导致的列解析错误是一个典型的查询优化器问题，反映了复杂SQL处理中的挑战。通过理解问题本质和采用适当的规避方案，用户可以有效地避免这类错误，确保查询的稳定执行。同时，这也提醒我们在数据库查询设计中需要权衡语法简洁性和执行可靠性。