Supabase Auth中refresh_tokens索引优化实践

在Supabase Auth系统的性能优化过程中，我们发现了一个关于refresh_tokens表索引使用的关键问题。这个问题直接影响用户会话管理的效率，特别是在处理用户注销或令牌刷新时的性能表现。

问题背景

refresh_tokens表是Supabase Auth系统中存储用户刷新令牌的核心表。该表原本设计了一个复合索引，包含instance_id和user_id两个字段。然而在实际查询中，系统经常仅使用user_id字段进行删除操作，导致索引无法被高效利用。

技术分析

通过EXPLAIN ANALYZE命令对查询计划进行分析，我们发现两种不同查询方式的性能差异显著：

1. 仅使用user_id条件查询：执行时间约35毫秒

   • 数据库虽然使用了复合索引，但由于缺少instance_id条件，导致索引扫描效率低下
   • 查询计划显示需要扫描大量行(13318.67行的估算成本)

2. 同时使用instance_id和user_id条件查询：执行时间仅0.271毫秒

   • 数据库能够充分利用复合索引进行高效查找
   • 查询计划显示扫描行数大幅减少(17.68行的估算成本)

问题根源

问题的核心在于索引设计原则与实际查询模式不匹配。复合索引的最左前缀原则要求查询必须包含索引的最左侧字段才能充分利用索引。refresh_tokens表的索引以instance_id为首字段，但实际查询经常只使用user_id条件，导致：

1. 索引无法被完全利用
2. 数据库退化为低效的索引扫描
3. 系统资源浪费
4. 用户体验下降（响应时间延长）

解决方案

针对这一问题，Supabase团队实施了以下优化措施：

1. 查询优化：修改相关SQL语句，确保在删除操作中包含instance_id条件
2. 索引调整：考虑是否需要调整索引结构，将更常用的查询条件放在复合索引的前面
3. 代码审查：检查所有涉及refresh_tokens表的操作，确保索引被正确使用

实际效果

优化后，相关查询的性能提升了约130倍（从35ms降至0.271ms）。这一改进显著提高了：

• 用户注销体验
• 令牌刷新效率
• 系统整体响应速度
• 数据库资源利用率

经验总结

这个案例为我们提供了几个重要的数据库优化经验：

1. 索引设计必须匹配查询模式：复合索引的字段顺序应根据实际查询条件的使用频率和选择性进行设计
2. 定期性能分析至关重要：通过EXPLAIN ANALYZE等工具持续监控查询性能
3. 全栈视角优化：数据库优化不仅涉及DBA工作，也需要开发人员在编写SQL时考虑索引使用情况
4. 真实数据测试：性能测试应使用接近生产环境的数据量和分布

Supabase Auth团队通过这一优化，显著提升了系统的稳定性和响应速度，为用户提供了更流畅的认证体验。