YugabyteDB中ORDER BY DESC在UNIQUE DEFAULT列上可能读取已删除数据的问题分析

问题现象

在YugabyteDB中，当表包含带有UNIQUE约束和DEFAULT值的列时，使用ORDER BY DESC进行降序查询可能会读取到已经被删除的数据行。具体表现为：

1. 创建一个包含UNIQUE DEFAULT列的表
2. 插入一行数据
3. 删除这行数据
4. 普通查询确认数据已删除
5. 使用GROUP BY和ORDER BY DESC组合查询时，却返回了已删除的数据

问题复现步骤

-- 创建测试表
CREATE TABLE t1(c0 int UNIQUE DEFAULT 1);

-- 插入测试数据
INSERT INTO t1(c0) VALUES (2);

-- 删除数据
DELETE FROM t1;

-- 普通查询确认数据已删除（返回0行）
SELECT * FROM t1;

-- 使用GROUP BY和ORDER BY DESC组合查询（意外返回已删除的数据）
SELECT * FROM t1 GROUP BY t1.c0 ORDER BY t1.c0 DESC;

技术背景

这个问题与YugabyteDB的查询执行引擎实现有关，特别是涉及到以下技术点：

1. UNIQUE约束与DEFAULT值：当列同时具有UNIQUE约束和DEFAULT值时，系统需要特殊处理以确保数据一致性。

2. 快速反向扫描优化：YugabyteDB为了提高查询性能，在某些场景下会使用快速反向扫描（fast backward scan）技术来优化ORDER BY DESC查询。

3. 数据删除机制：YugabyteDB作为分布式数据库，删除操作实际上是标记删除，数据可能不会立即从存储中物理清除。

问题根源

经过技术团队分析，该问题的根本原因在于：

1. 当禁用yb_use_hash_splitting_by_default参数时，快速反向扫描优化可能会错误地访问已标记删除但尚未物理清除的数据。

2. 在特定查询组合（GROUP BY + ORDER BY DESC）下，查询优化器选择了不正确的扫描路径，绕过了正常的可见性检查。

3. UNIQUE DEFAULT列的特殊处理与快速反向扫描优化之间存在不兼容性，导致已删除数据被错误地包含在结果集中。

解决方案

目前YugabyteDB团队已经采取了以下措施：

1. 暂时禁用了快速反向扫描优化功能（通过#26074变更），作为短期解决方案。

2. 正在开发更完善的修复方案，以确保快速反向扫描能够正确处理已删除数据的可见性检查。

用户建议

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

1. 保持yb_use_hash_splitting_by_default参数为默认值（true），避免触发问题场景。

2. 如果必须使用ORDER BY DESC查询，可以考虑添加额外的过滤条件或使用其他查询方式绕过问题。

3. 关注YugabyteDB的版本更新，及时升级到包含完整修复的版本。

技术启示

这个问题揭示了分布式数据库系统中几个重要的设计考量：

1. 查询优化与数据一致性：性能优化必须在不破坏数据一致性的前提下进行，特别是在涉及数据可见性的场景。

2. 特殊约束处理：UNIQUE、DEFAULT等约束的实现需要与查询执行引擎深度整合，避免出现边界条件问题。

3. 删除语义：在分布式环境中，删除操作的实现和可见性保证需要特别谨慎设计，确保所有查询路径都能正确遵守。

这个问题也提醒我们，在数据库系统设计和实现中，查询优化器与存储引擎的交互是一个复杂而微妙的领域，需要全面的测试覆盖来确保各种查询组合都能正确执行。