YugabyteDB中排序部分索引在DISTINCT查询时的性能优化

问题背景

在YugabyteDB 2024.2版本中，当使用带有排序的部分索引执行DISTINCT查询时，即使查询已经预处理(prepared)，系统仍然会产生额外的目录(catalog)请求，这会影响查询性能。

问题复现

我们创建一个测试表tbl1，包含18个不同类型的列，然后创建一个预处理查询query_tbl1，该查询使用DISTINCT关键字并包含多个过滤条件。为了优化这个查询，我们创建了一个名为idx_tbl1_filtered_sorted的部分索引，该索引：

1. 只包含col18值为'Held'或'Failed'的记录
2. 按照col1和col13(降序)排序
3. 包含了查询中需要的所有列

当执行这个预处理查询时，EXPLAIN ANALYZE输出显示虽然存储层只读取了1次索引(Storage Index Read Requests: 1)，但却产生了17次目录读取请求(Catalog Read Requests: 17)，这显然不是最优的表现。

技术分析

在理想情况下，预处理查询应该能够充分利用已有的索引信息，避免重复访问目录。但在这个案例中，系统仍然需要多次访问目录，可能的原因包括：

1. 预处理查询没有完全缓存索引元数据
2. 排序部分索引的特殊性导致优化器需要额外验证
3. DISTINCT操作与部分索引的交互存在问题

解决方案

这个问题在后续版本中通过两个途径得到了解决：

1. 短期解决方案(#26058)：通过特定的代码修改，减少了在这种情况下不必要的目录访问
2. 长期解决方案(#25957)：从根本上优化了预处理查询与部分索引的交互机制

性能影响

从EXPLAIN ANALYZE的输出可以看到，虽然实际数据读取很快(Storage Index Read Execution Time: 1.396 ms)，但目录访问时间却占了很大比例(Catalog Read Execution Time: 8.080 ms)。修复后，这部分开销将显著降低。

最佳实践

对于使用YugabyteDB的开发人员，在处理类似场景时建议：

1. 尽量使用包含所有查询列的覆盖索引
2. 对于复杂查询，考虑使用预处理语句
3. 定期检查EXPLAIN ANALYZE输出，关注目录访问次数
4. 在性能关键的查询中使用部分索引时，注意测试不同版本的行为差异

这个问题展示了数据库优化器在处理复杂查询时可能遇到的挑战，也体现了YugabyteDB团队持续优化查询性能的努力。