SuperTokens核心库中的用户ID映射查询性能问题分析与解决方案

问题背景

在Supertokens核心库的生产环境部署中，开发团队遇到了严重的性能问题，最终导致系统宕机。通过分析发现，问题根源在于用户ID映射表(st_userid_mapping)的查询效率低下，特别是当系统负载较高时，这个问题会进一步恶化。

问题分析

查询性能瓶颈

系统中最耗时的查询语句是：

SELECT * FROM subscriberdb.st_userid_mapping 
WHERE app_id = 'public' 
AND (supertokens_user_id = '123' OR external_user_id = '123');

这个查询存在两个主要问题：

1. OR条件导致索引失效：查询条件中使用了OR操作符连接两个不同的列(supertokens_user_id和external_user_id)，这会导致数据库无法有效利用这两个列上的索引。数据库优化器通常难以同时使用两个单列索引来优化OR条件查询。

2. 行锁争用：在高并发环境下，频繁执行这样的低效查询会导致大量行被锁定，进而引发严重的锁争用问题。从系统监控截图可以看到，这直接导致了第二次系统宕机。

影响范围

这个问题对系统的影响是全局性的：

• 响应时间显著增加
• 数据库CPU和I/O负载飙升
• 最终导致整个系统不可用

解决方案

技术实现

修复方案的核心思路是重写查询逻辑，避免使用OR条件。可以采用以下两种方式之一：

1. 使用UNION ALL合并两个查询结果：

SELECT * FROM subscriberdb.st_userid_mapping 
WHERE app_id = 'public' AND supertokens_user_id = '123'
UNION ALL
SELECT * FROM subscriberdb.st_userid_mapping 
WHERE app_id = 'public' AND external_user_id = '123'

2. 使用两个独立查询并在应用层合并结果

这两种方式都能确保数据库优化器可以充分利用单列索引，显著提高查询效率。

实施效果

开发团队通过构建自定义的核心Docker镜像并部署修复后的版本，系统性能立即恢复正常水平。这表明解决方案有效地解决了原始查询导致的性能瓶颈问题。

经验总结

这个案例为我们提供了几个重要的技术经验：

1. OR条件的谨慎使用：在SQL查询中，OR条件往往会导致索引失效，特别是在连接不同列的查询中。开发时应特别注意这类查询的性能影响。

2. 生产环境监控的重要性：及时发现并定位性能瓶颈是保障系统稳定性的关键。在这个案例中，通过RDS的性能监控快速定位到了问题查询。

3. 数据库设计考量：对于频繁查询的多条件场景，应考虑创建复合索引或调整查询模式，而不是依赖数据库优化器来处理复杂的条件组合。

4. 高并发下的锁争用：低效查询不仅影响单个请求的性能，在高并发环境下还会引发锁争用，导致系统级故障。

这个问题的修复已经包含在Supertokens核心库的v10.0.0版本中，为所有用户提供了更稳定可靠的性能表现。