YugabyteDB中SELECT DISTINCT查询的目录查找性能优化分析

问题背景

在YugabyteDB的YSQL层中，某些包含SELECT DISTINCT的查询在执行时会出现重复的目录查找操作，这会导致不必要的性能开销。具体表现为当执行带有复合条件过滤的DISTINCT查询时，系统会多次访问pg_amop系统目录表。

问题复现

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

1. 首先创建一个测试表并建立索引：

create table example(t1 text, u2 uuid, t3 text);
create index ex_idx on example(t1 asc, u2 asc, t3 asc);

2. 执行一个带有复合条件的DISTINCT查询：

select distinct (t1, u2, t3) from example 
where u2 = '00000000-0000-0000-0000-000000000000'::uuid AND t1 = 'foo';

3. 启用调试日志后，可以看到系统在执行过程中进行了多次不必要的pg_amop目录查找。

技术分析

这个问题源于YugabyteDB优化器在处理DISTINCT查询时的逻辑顺序。当前实现中，优化器会先检查操作符策略是否为等值比较(BTEqualStrategyNumber)，然后再验证是否是"索引键=常量"的形式。这种顺序导致了不必要的目录查找。

更合理的做法应该是：

1. 先检查查询条件是否是"索引键=常量"的形式
2. 只有在确认是这种形式后，才去查找操作符策略

解决方案

通过调整检查顺序可以显著减少目录查找次数。核心修改思路是：

1. 首先验证查询条件是否是"索引键=常量"的形式
2. 只有在确认是这种形式后，才去查询操作符策略
3. 最后验证操作符策略是否为等值比较

这种优化虽然看似简单，但能有效减少系统目录访问次数，特别是在频繁执行的查询场景下，可以累积节省可观的性能开销。

性能影响

在实际测试中，这种优化可以：

• 消除不必要的目录查找请求
• 减少查询执行时间
• 降低系统负载
• 提高整体吞吐量

特别是在高并发场景下，这种优化能够显著减少系统目录表的争用，提升整体系统稳定性。

总结

YugabyteDB作为一个分布式数据库，其性能优化需要从各个层面进行细致考量。这个案例展示了即使是简单的检查顺序调整，也能带来明显的性能提升。对于数据库开发者而言，这提醒我们在编写优化器代码时需要特别注意系统目录访问的开销，合理安排检查逻辑的顺序。