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

问题背景

在Supabase Auth项目中，用户表(users)的recovery_token字段设计用于密码重置流程。该字段上创建了一个带有条件的唯一索引，但实际查询中却发现该索引未被有效利用，导致查询性能低下。

问题现象

开发团队发现，执行类似以下的查询语句时，数据库没有使用已创建的索引，而是进行了全表扫描(seq_scan)：

SELECT * FROM auth.users WHERE recovery_token = 'abc' AND is_sso_user = false LIMIT 1;

这种查询在实际应用中频繁执行，占用了大量数据库资源，平均查询时间达到1500毫秒，严重影响了系统性能。

索引分析

检查发现users表上存在如下索引定义：

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

这个索引有两个特点：

1. 它是一个条件索引(partial index)，只有当recovery_token不匹配正则表达式'^[0-9 ]*$'时才被包含在索引中
2. 它是一个唯一索引(UNIQUE)

问题根源

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

1. 条件索引的限制：当recovery_token值为纯数字或空格时，不符合索引条件，导致查询优化器无法使用该索引

2. 查询条件组合：查询中同时包含recovery_token和is_sso_user条件，而索引只包含recovery_token字段，优化器可能认为索引选择性不足

3. 统计信息不准确：PostgreSQL的查询优化器依赖统计信息来决定是否使用索引，如果统计信息过时或不准确，可能导致错误的执行计划

解决方案

针对这个问题，Supabase团队采取了以下改进措施：

1. 修改索引定义：移除了索引中的条件限制，使所有recovery_token值都能被索引

2. 增加复合索引：考虑创建包含recovery_token和is_sso_user的复合索引，提高查询效率

3. 更新统计信息：定期执行ANALYZE命令，确保查询优化器有最新的统计信息

实施效果

经过索引优化后，相关查询的执行计划从全表扫描变为索引扫描，查询性能得到显著提升：

• 查询时间从1500毫秒降至毫秒级
• 数据库负载降低
• 系统整体响应速度改善

最佳实践建议

对于类似场景，建议开发者：

1. 定期检查关键查询的执行计划，确保索引被正确使用
2. 避免在频繁查询的字段上使用条件索引，除非有特殊需求
3. 对于组合条件查询，考虑创建复合索引
4. 监控数据库性能指标，及时发现潜在问题

通过这次优化，Supabase Auth项目的密码重置流程性能得到了显著提升，为用户提供了更好的体验。