Dolt数据库中的SELECT DISTINCT查询优化问题分析

问题背景

在Dolt数据库系统中，我们发现了一个关于SELECT DISTINCT查询的性能优化问题。当执行带有DISTINCT关键字的查询时，系统会不必要地加载所有列数据，即使这些列并不出现在最终结果集中。相比之下，使用GROUP BY的类似查询则能够正确地只加载需要的列。

问题复现

通过以下示例可以清晰地复现这个问题：

CREATE TABLE Products(
    ProductID Char(38) PRIMARY KEY, /*UUID*/
    Manufacturer TEXT,
    ProductSeries TEXT,
    ProductName TEXT);

-- 使用DISTINCT的查询
EXPLAIN PLAN SELECT DISTINCT Manufacturer, ProductSeries FROM Products;

-- 使用GROUP BY的查询
EXPLAIN PLAN SELECT Manufacturer, ProductSeries FROM Products GROUP BY Manufacturer, ProductSeries;

执行计划对比

DISTINCT查询的执行计划：

Distinct
 └─ Project
     ├─ columns: [products.Manufacturer, products.ProductSeries]
     └─ Table
         └─ name: Products

GROUP BY查询的执行计划：

GroupBy
 ├─ SelectedExprs(products.Manufacturer, products.ProductSeries)
 ├─ Grouping(products.manufacturer, products.productseries)
 └─ Table
     ├─ name: Products
     └─ columns: [manufacturer productseries]

问题分析

从执行计划可以看出，DISTINCT查询在底层表扫描时没有进行列裁剪优化，这意味着即使查询只需要Manufacturer和ProductSeries两列，系统仍然会加载包括ProductName在内的所有列数据。这会导致：

1. 不必要的I/O操作：系统需要从存储中读取更多数据
2. 内存浪费：加载的数据量增加，占用更多内存
3. 性能下降：特别是对于包含大文本字段的表，影响更为显著

相比之下，GROUP BY查询正确地应用了列裁剪优化，只加载查询实际需要的列。

技术原理

在SQL查询优化中，列裁剪(Column Pruning)是一种重要的优化技术。其基本原理是：

1. 分析查询计划树，确定最终结果集需要的列
2. 向上传播这些列需求到数据源
3. 在扫描表时只读取必要的列

在Dolt的查询优化器中，GROUP BY路径已经实现了这种优化，但DISTINCT路径似乎遗漏了这一优化。

影响范围

这个问题主要影响：

1. 包含大量列特别是大文本字段的表
2. 频繁使用SELECT DISTINCT的查询
3. 数据量大的表，因为I/O开销更为明显

解决方案建议

要解决这个问题，可以考虑以下方向：

1. 在查询计划生成阶段，为DISTINCT操作添加列裁剪逻辑
2. 统一GROUP BY和DISTINCT的列处理逻辑，因为它们本质上是相似的集合操作
3. 在查询优化器中添加专门的规则来处理DISTINCT的列需求

性能影响评估

假设一个表有：

• 10个小型列（每列约100字节）
• 5个大型文本列（每列约10KB）

对于只需要2个小列的查询：

• 优化前：需要读取约50KB数据（所有列）
• 优化后：只需读取约200字节数据（仅需要的列）

性能提升可达250倍，特别是在网络传输或磁盘I/O成为瓶颈的场景下。

总结

Dolt数据库中的SELECT DISTINCT查询目前存在列裁剪优化缺失的问题，这会导致不必要的性能开销。通过分析执行计划和查询优化原理，我们发现这一问题可以通过扩展现有的列裁剪优化逻辑来解决。对于使用Dolt并频繁执行DISTINCT查询的用户，建议关注此问题的修复进展，以获得更好的查询性能。