Supabase Auth中recovery_token索引未生效问题分析与解决方案

问题背景

在Supabase Auth项目中，用户表(users)的恢复令牌(recovery_token)字段设计了一个特殊的索引，用于加速密码重置等关键操作。然而在实际生产环境中，开发者发现基于recovery_token的查询性能极差，查询时间高达1500毫秒，占用了8%的数据库资源。

问题现象

通过EXPLAIN ANALYZE分析查询计划发现，系统在执行包含recovery_token条件的查询时，没有使用预设的索引，而是进行了全表扫描(seq_scan)。例如以下查询：

SELECT * FROM auth.users WHERE recovery_token = 'abc';

索引设计分析

项目中原有的索引定义如下：

CREATE UNIQUE INDEX recovery_token_idx ON auth.users 
USING btree (recovery_token) 
WHERE ((recovery_token)::text !~ '^[0-9 ]*$'::text)

这个索引设计有几个特点：

1. 使用了BTREE索引结构
2. 添加了条件过滤，仅索引不符合正则表达式'^[0-9 ]*$'的recovery_token值
3. 是唯一索引(UNIQUE)

问题根源

经过分析，索引未被使用的主要原因包括：

1. 条件索引的限制：索引带有WHERE条件，只有当查询条件与索引条件匹配时，优化器才会考虑使用该索引。而常规查询没有包含这个条件。

2. 数据类型转换：索引条件中对recovery_token进行了显式的文本转换(::text)，这可能影响优化器的决策。

3. 查询模式不匹配：实际查询中通常还包含其他条件如is_sso_user，这可能使优化器认为全表扫描更高效。

解决方案

Supabase团队已经部署了修复方案，主要改进包括：

1. 简化索引条件：移除了不必要的条件过滤，使索引能够覆盖更广泛的查询场景。

2. 优化索引结构：确保索引能够被各种常见的查询模式所利用。

3. 查询重写：在应用层优化查询语句，使其更符合索引使用条件。

验证与监控

开发者可以通过以下方式验证修复效果：

1. 使用EXPLAIN ANALYZE检查查询计划，确认是否使用了索引。

2. 监控查询性能指标，特别是执行时间和资源占用。

3. 检查数据库的索引使用统计，确认新索引的实际利用率。

最佳实践建议

对于类似场景，建议：

1. 索引设计应尽量匹配常见的查询模式。

2. 避免在索引条件中使用过于复杂的表达式。

3. 定期检查索引使用情况，删除无用索引，优化低效索引。

4. 对于关键业务查询，应进行专门的性能测试和优化。

Supabase Auth团队将持续监控此问题的解决效果，并根据需要进一步优化数据库索引策略。