TiDB中DISTINCT与NULL安全等于操作符(<=>)在JOIN中的异常行为分析

问题背景

在数据库查询中，我们经常会使用DISTINCT关键字来去除重复行，以及使用NULL安全等于操作符(<=>)来处理可能包含NULL值的比较。然而，在TiDB v8.5.1版本中，当这两种操作结合使用时，出现了查询结果不符合预期的现象。

问题现象

我们通过一个具体的示例来说明这个问题。考虑以下SQL查询：

WITH base (c1, c2) AS (
  SELECT DISTINCT 1, 'Alice'
  UNION
  SELECT NULL, 'Bob' 
),
base2 (c1, c3) AS (
  SELECT 1, 100
  UNION
  SELECT NULL, NULL
)
SELECT * FROM base
INNER JOIN base2 ON base.c1 <=> base2.c1;

在TiDB v8.5.1中，这个查询只返回了一行结果：

+------+-------+------+------+
| c1   | c2    | c1   | c3   |
+------+-------+------+------+
|    1 | Alice |    1 |  100 |
+------+-------+------+------+

然而，在TiDB v8.1.2和MySQL 8.0.33中，这个查询正确地返回了两行结果，包括NULL值的匹配：

+------+-------+------+------+
| c1   | c2    | c1   | c3   |
+------+-------+------+------+
|    1 | Alice |    1 |  100 |
| NULL | Bob   | NULL | NULL |
+------+-------+------+------+

问题分析

1. 预期行为

在SQL标准中，NULL安全等于操作符(<=>)的设计目的就是专门处理NULL值的比较。当两个操作数都是NULL时，<=>会返回TRUE，这与普通的等于操作符(=)不同。因此，在JOIN操作中使用<=>时，NULL值应该能够相互匹配。

2. 异常行为

在TiDB v8.5.1中，当查询中包含DISTINCT关键字时，NULL值的匹配似乎被忽略了。这显然不符合SQL标准的行为。值得注意的是：

• 如果移除DISTINCT关键字，查询会返回正确的结果
• 这个问题在v8.5.0及更早版本中不存在，是在v8.5.1中引入的回归问题

3. 技术原因

经过调查，这个问题与TiDB内部对DISTINCT和JOIN操作的优化处理有关。在v8.5.1中，某些优化可能导致NULL值的处理逻辑出现了偏差，特别是在使用NULL安全等于操作符时。

解决方案

对于遇到此问题的用户，可以采取以下临时解决方案：

1. 如果业务允许，暂时避免在包含NULL值比较的JOIN操作中使用DISTINCT
2. 降级到v8.5.0版本，等待修复版本发布
3. 使用其他方式实现去重，例如GROUP BY

总结

这个问题展示了数据库查询优化中一个有趣的边界情况。虽然优化器改进通常会提高性能，但有时也可能引入新的问题。作为开发者，我们需要：

1. 充分理解各种SQL操作符的语义，特别是涉及NULL处理的特殊操作符
2. 在升级数据库版本后，对关键查询进行验证测试
3. 关注数据库的发行说明，了解已知问题和修复情况

TiDB团队已经确认了这个问题，并将在后续版本中修复。对于依赖NULL值处理的应用，建议在升级前进行充分的测试验证。