EdgeDB中IN操作符索引失效问题分析

问题现象

在EdgeDB数据库中使用IN操作符进行查询时，发现了一个性能异常现象：当直接使用IN操作符查询一组UUID值时，查询耗时显著高于将相同UUID值转换为数组后再使用IN array_unpack查询的方式。

具体案例

测试案例中查询Person表中ID在特定UUID集合中的记录：

1. 直接使用IN操作符查询：

select Person filter .id IN <uuid>{
  '99c3b73e-2f95-11f0-93a5-2f6181ea99b9',
  '99c3b73f-2f95-11f0-93a5-ff2a997bf491',
  '99c3b740-2f95-11f0-93a5-6f9dfd87429e'
};

查询耗时约1.34秒

2. 使用array_unpack方式查询：

select Person filter .id IN array_unpack(array_agg(<uuid>{
  '99c3b73e-2f95-11f0-93a5-2f6181ea99b9',
  '99c3b73f-2f95-11f0-93a5-ff2a997bf491',
  '99c3b740-2f95-11f0-93a5-6f9dfd87429e'
}));

查询耗时仅52.6毫秒

问题分析

这个现象表明EdgeDB在处理IN操作符时存在优化不足的问题：

1. 索引使用差异：直接使用IN操作符时，数据库可能没有有效利用id字段上的索引，导致全表扫描。而array_unpack方式则可能触发了更优化的查询计划。

2. 集合与数组处理差异：EdgeDB内部对集合(set)和数组(array)的处理逻辑可能存在差异，导致优化器生成不同的执行计划。

3. 查询重写优化：在某些数据库中，IN列表会被重写为多个OR条件，而大IN列表可能导致优化器放弃使用索引。array_unpack可能避免了这种重写。

临时解决方案

在实际应用中，如果遇到类似性能问题，可以采用以下临时解决方案：

1. 将IN列表转换为数组并使用array_unpack函数，如示例所示。

2. 对于大量值的情况，考虑使用JOIN方式替代IN操作符。

3. 评估是否可以将查询拆分为多个小查询，通过应用层合并结果。

技术背景

数据库优化器在处理IN操作符时通常有以下几种策略：

1. 哈希连接：将IN列表中的值构建为哈希表，然后扫描表进行匹配。

2. 二分查找：如果IN列表有序且字段有索引，可以使用二分查找。

3. OR条件展开：将IN条件重写为多个OR条件。

在EdgeDB的这个案例中，直接使用IN操作符可能选择了效率较低的查询计划，而array_unpack方式触发了更优的执行路径。

总结

这个案例展示了数据库查询优化中一个有趣的现象：看似更复杂的查询写法(array_unpack)反而比简单的IN操作符性能更好。开发者在遇到查询性能问题时，不应局限于常规写法，可以尝试不同的查询构造方式。同时，这也提示数据库开发者需要持续优化查询优化器对各种语法结构的处理能力。