TiDB 中涉及子查询、左连接和内连接的错误连接结果分析

问题背景

在 TiDB 数据库系统中，发现了一个关于查询执行计划的严重问题。该问题出现在涉及子查询、左连接(LEFT JOIN)和内连接(INNER JOIN)的复杂查询场景中，导致查询结果与预期不符。

问题重现

通过以下测试用例可以重现该问题：

首先创建测试表并插入数据：

CREATE TABLE t0(c0 BOOL);
CREATE TABLE t1(c0 CHAR);

INSERT INTO t1 VALUES (NULL);
INSERT INTO t0(c0) VALUES (false);

然后执行以下查询：

-- 简单左连接查询，结果正确
SELECT *
FROM t1
LEFT JOIN (SELECT (0) AS col_0 FROM t0) as subQuery1 
ON ((subQuery1.col_0) = (t1.c0));

-- 加入内连接条件为false，结果正确(空集)
SELECT *
FROM t1
LEFT JOIN (SELECT (0) AS col_0 FROM t0) as subQuery1 
ON ((subQuery1.col_0) = (t1.c0))
INNER JOIN t0 ON (false);

-- 问题查询：使用<=>运算符的内连接，结果错误
SELECT *
FROM t1
LEFT JOIN (SELECT (0) AS col_0 FROM t0) as subQuery1 
ON ((subQuery1.col_0) = (t1.c0))
INNER JOIN t0 ON (subQuery1.col_0 <=> t0.c0);

最后一个查询预期应该返回空结果集，因为NULL <=> 0的结果是false，但实际却返回了包含NULL值的行。

问题分析

通过对比不同 TiDB 版本的执行计划，可以发现：

在正确版本(v7.5.6)中，执行计划保持了原始查询的顺序：

1. 先执行左连接
2. 然后执行内连接，使用nulleq条件

而在有问题的版本中，执行计划被优化器重新排序：

1. 先执行内连接
2. 然后执行左连接

这种执行顺序的改变导致了错误的结果。根本原因在于当内连接支持nulleq运算符后，左连接重排序的等价性不再得到保证。

解决方案

目前有以下几种临时解决方案：

1. 禁用外连接重排序优化：

SET tidb_enable_outer_join_reorder=0;

2. 使用STRAIGHT_JOIN提示强制保持连接顺序：

SELECT /*+ straight_join() */ * FROM ...

对于数据库开发者，需要修复优化器中关于连接重排序的逻辑，确保在使用nulleq条件时不会破坏查询语义。

技术细节

这个问题涉及到数据库查询优化中的几个关键概念：

1. 连接重排序：查询优化器会尝试重新排列连接顺序以提高性能，但必须保证语义不变。

2. NULL处理：在SQL中，NULL与任何值的比较都是特殊的，<=>运算符是MySQL/TiDB特有的NULL安全等于运算符。

3. 执行计划生成：优化器需要正确处理包含子查询、外连接和特殊比较条件的复杂查询。

这个问题提醒我们，在数据库优化器开发中，任何优化转换都必须严格保证语义等价性，特别是在处理NULL值和复杂查询结构时。