Supabase GoTrue 项目中索引优化实践：refresh_tokens 表性能问题分析

问题背景

在 Supabase 的认证服务 GoTrue 中，refresh_tokens 表是存储用户刷新令牌的关键数据表。开发团队发现该表在执行按用户ID删除令牌的操作时出现了明显的性能问题，查询耗时达到了35毫秒级别，这在认证服务的高并发场景下是不可接受的。

问题分析

通过深入分析，发现问题的根源在于表索引的设计和使用方式。refresh_tokens 表上存在一个复合索引(instance_id, user_id)，但当执行仅基于user_id的删除操作时，数据库无法高效利用这个索引。

具体表现为：

1. 仅使用user_id条件查询时，执行时间约为35毫秒
2. 同时使用instance_id和user_id条件查询时，执行时间骤降至0.27毫秒

这种性能差异表明，现有的索引设计没有为常见的单字段查询场景提供最佳支持。

技术原理

PostgreSQL 的索引使用遵循"最左前缀"原则。对于复合索引(instance_id, user_id)：

1. 当查询条件包含instance_id时，可以充分利用索引
2. 当查询条件仅包含user_id时，索引效果会大打折扣
3. 索引列的顺序直接影响查询性能

在认证服务的实际场景中，按user_id删除refresh_token是一个高频操作，特别是在用户注销或令牌轮换时。因此，需要针对这一场景优化索引设计。

解决方案

针对这一问题，开发团队采取了以下优化措施：

1. 为user_id单独创建索引，确保按用户ID查询的高效性
2. 保留原有的复合索引，以支持同时按instance_id和user_id查询的场景
3. 优化相关SQL语句，确保查询能够使用最合适的索引

这种优化策略遵循了数据库索引设计的最佳实践：为高频查询场景创建专用索引，同时保持复合索引的灵活性。

实际效果

优化后，按user_id删除refresh_token的操作性能提升了约130倍，从35毫秒降至0.27毫秒。这一改进显著提升了认证服务的整体性能，特别是在高并发场景下的响应速度。

经验总结

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

1. 索引设计应考虑实际查询模式，而不仅仅是数据关系
2. 高频查询应优先考虑专用索引而非复合索引
3. 定期分析慢查询日志是发现性能问题的有效手段
4. 在认证服务等关键系统中，毫秒级的性能优化也可能带来显著的整体提升

对于使用Supabase的开发者来说，这一优化已经包含在最新版本中，无需额外操作即可享受性能提升。这也体现了开源项目通过社区反馈持续改进的优越性。