Keycloak角色删除性能问题分析与优化

问题背景

在Keycloak身份和访问管理系统中，当数据库中存在大量角色记录时（例如40万条），删除单个角色的操作会变得异常缓慢。这一性能问题尤其严重，甚至会导致包含少量角色的整个领域(realm)删除操作超时。

技术分析

问题的根源在于Keycloak 26.0版本中的一个变更(commit 83c00731c3a103b86007d7402c77ed5ebb7a517b)引入的JPA查询效率问题。当执行角色删除操作时，系统需要检查该角色是否被其他复合角色引用。

原始查询使用了JPA的"member of"语法：

select role from RoleEntity role where :compositeRole member of role.compositeRoles

这会被转换为以下SQL查询：

select re1_0.ID,re1_0.CLIENT,... from KEYCLOAK_ROLE re1_0 
where ? in (select cr1_0.CHILD_ROLE from COMPOSITE_ROLE cr1_0 where re1_0.ID=cr1_0.COMPOSITE)

在PostgreSQL 16.6(Aurora)上，这个查询的执行计划显示：

• 对KEYCLOAK_ROLE表进行全表扫描(Seq Scan)
• 对每行记录执行子查询检查
• 整体成本高达1,827,365.87

性能瓶颈

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

1. 全表扫描：即使COMPOSITE_ROLE表只有316条记录，也要扫描整个40万行的KEYCLOAK_ROLE表
2. 嵌套循环：对每行角色记录都要执行一次子查询，导致性能呈O(n)级别下降

优化方案

理想的查询应该是：

select * from KEYCLOAK_ROLE re1_0 
where ID in (select cr1_0.CHILD_ROLE from COMPOSITE_ROLE cr1_0 where cr1_0.CHILD_ROLE = '角色ID')

优化后的执行计划：

• 使用索引扫描(Index Scan)直接定位角色
• 通过嵌套循环半连接(Nested Loop Semi Join)高效关联
• 整体成本仅16.74，性能提升显著

影响范围

该问题主要影响：

• 大规模部署环境（角色数量超过10万）
• 使用PostgreSQL数据库的系统
• Keycloak 26.0及以上版本

解决方案

Keycloak团队已将该修复反向移植到26.2.3和26.3.0版本中。对于生产环境，建议：

1. 升级到包含修复的版本
2. 对于无法立即升级的系统，可考虑手动优化相关JPA查询
3. 定期清理未使用的角色，保持数据库精简

总结

数据库查询优化是身份管理系统性能调优的关键环节。通过分析执行计划和重构查询方式，Keycloak团队成功解决了大规模角色删除的性能瓶颈，为高负载环境下的稳定运行提供了保障。这也提醒开发者在设计JPA查询时，需要充分考虑数据规模增长对性能的影响。